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