[OpenAFS-devel] How can the mem cache possibly not be able to allocate memory?

[Neulinger, Nathan]

Interesting, I was reading that vmalloc should almost NEVER be used,
since it forces the kernel to do page table operations that don't have
to be done with kmalloc, and that the shortcoming of kmalloc is that it
cannot do _large_ contiguous allocations. Supposedly vmalloc is not very
smp friendly, and cannot be used in an interrupt as well.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216
=20

> -----Original Message-----
> From: chas williams (contractor) [mailto:chas@cmf.nrl.navy.mil]=20
> Sent: Monday, April 12, 2004 11:30 AM
> To: Neulinger, Nathan
> Cc: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] How can the mem cache possibly=20
> not be able to allocate memory?=20
>=20
> typically the only reason to use kmalloc() for regions greater than a
> single page is that you need the region to be continguous in physical
> memory.  for instance, a bounce buffer for some hardware.
>=20
> really afs could just use vmalloc() for everything i suspect.
>=20
> In message=20
> <5C51DC2B8353AB4BA2CD04B34F2EE79C3EFE8D@umr-umail1.umr.edu>,"N
> eulinger, Nathan" writes:
> >As a note - from taking a look at some of the linux kernel=20
> discussions,
> >it looks like kmalloc can be used for up to 32*pagesize=20
> bytes (128k)...
> >any idea why our threshold is set to just 1 page?
> >
> >-- Nathan
> >
> >------------------------------------------------------------
> >Nathan Neulinger                       EMail:  nneul@umr.edu
> >University of Missouri - Rolla         Phone: (573) 341-6679
> >UMR Information Technology             Fax: (573) 341-4216
> >=20
> >
> >> -----Original Message-----
> >> From: Neulinger, Nathan=20
> >> Sent: Monday, April 12, 2004 11:02 AM
> >> Cc: 'openafs-devel@openafs.org'
> >> Subject: RE: [OpenAFS-devel] How can the mem cache possibly=20
> >> not be able to allocate memory?=20
> >>=20
> >> AFS osi_alloc appears to be thresholding at MAX_KMALLOC_SIZE.=20
> >> If <=3D, it uses kmalloc, otherwise vmalloc. MAX_KMALLOC_SIZE=20
> >> is set to PAGE_SIZE.
> >>=20
> >> -- Nathan
> >>=20
> >> ------------------------------------------------------------
> >> Nathan Neulinger                       EMail:  nneul@umr.edu
> >> University of Missouri - Rolla         Phone: (573) 341-6679
> >> UMR Information Technology             Fax: (573) 341-4216
> >> =20
> >>=20
> >> > -----Original Message-----
> >> > From: chas williams (contractor) [mailto:chas@cmf.nrl.navy.mil]=20
> >> > Sent: Wednesday, April 07, 2004 10:01 PM
> >> > To: Neulinger, Nathan
> >> > Cc: openafs-devel@openafs.org
> >> > Subject: Re: [OpenAFS-devel] How can the mem cache possibly=20
> >> > not be able to allocate memory?=20
> >> >=20
> >> > In message <20040408014851.GA10203@umr.edu>,Nathan=20
> Neulinger writes:
> >> > >Apr  7 13:27:51 nic1 kernel: Memory: 4008596k/4194304k=20
> >> > available (2244k
> >> > >kernel code, 53668k reserved, 1432k data, 168k init,=20
> >> > 3145152k highmem)
> >> > >
> >> > >That just plain doesn't make any sense... I tried to=20
> give it a 75MB
> >> > >memcache... Is there something with how afs is trying to=20
> >> > allocate kernel
> >> > >memory that would limit what it could use?=20
> >> >=20
> >> > well the linux kernel could be placing a limit on memory.  i=20
> >> > would have
> >> > to guess that afs_osi_Alloc(memCacheBlkSize) is going to=20
> >> > using kmalloc()
> >> > instead of vmalloc().  kmalloc() gets its buffer from=20
> various pools
> >> > viewable from /proc/slabinfo (in particular the size-NNNN=20
> >> pools).  it
> >> > seems like you might be hitting a limit on the number of buffers.
> >> >=20
> >> > perhaps memcache should be implemented to have it own kmem_cache.
> >> >=20
> >> >=20
> >_______________________________________________
> >OpenAFS-devel mailing list
> >OpenAFS-devel@openafs.org
> >https://lists.openafs.org/mailman/listinfo/openafs-devel
> >
> >
>=20
>=20