On Tue, Jun 10, 2008 at 05:12:31PM -0500, Weathers, Norman R. wrote:
>
>
> > -----Original Message-----
> > From: J. Bruce Fields [mailto:[email protected]]
> > Sent: Tuesday, June 10, 2008 12:16 PM
> > To: Weathers, Norman R.
> > Cc: [email protected]
> > Subject: Re: Problems with large number of clients and reads
> >
> > On Tue, Jun 10, 2008 at 09:30:18AM -0500, Weathers, Norman R. wrote:
> > > Unfortunately, I cannot stop the clients (middle of long running
> > > jobs). I might be able to test this soon. If I have the number of
> > > threads high, yes I can reduce the number of threads and it
> > appears to
> > > lower some of the memory, but even with as little as three threads,
> > > the memory usage climbs very high, just not as high as if there are
> > > say 8 threads. When the memory usage climbs high, it can cause the
> > > box to not respond over the network (ssh, rsh), and even be very
> > > sluggish when I am connected over our serial console to the
> > server(s).
> > > This same scenario has been happening with kernels that I have tried
> > > from 2.6.22.x on to the 2.6.25 series. The 2.6.25 series is
> > > interesting in that I can push the same load from a box with the
> > > 2.6.25 kernel and not have a load over .3 (with 3 threads), but with
> > > the 2.6.22.x kernel, I have a load of over 3 when I hit the same
> > > conditions.
> >
> > OK, I think what we want to do is turn on
> > CONFIG_DEBUG_SLAB_LEAK. I've
> > never used it before, but it looks like it will report which functions
> > are allocating from each slab cache, which may be exactly what we need
> > to know. So:
> >
> > 1. Install a kernel with both CONFIG_DEBUG_SLAB ("Debug slab
> > memory allocations") and CONFIG_DEBUG_SLAB_LEAK ("Memory leak
> > debugging") turned on. They're both under the "kernel hacking"
> > section of the kernel config. (If you have a file
> > /proc/slab_allocators, then you already have these turned on and
> > you can skip this step.)
> >
> > 2. Do whatever you need to do to reproduce the problem.
> >
> > 3. Get a copy of /proc/slabinfo and /proc/slab_allocators.
> >
> > Then we can take a look at that and see if it sheds any light.
>
>
> I have taken several snapshots of the /proc/slab_allocators and
> /proc/slabinfo as requested, but since there is a lot of info in them,
> and I didn't think anyone wanted to go cross-eyed reading the data in an
> email, I have them up on a website:
>
> http://shashi-weathers.net/linux/cluster/NFS/
Excellent.
>
> The order of data collection is:
>
> slab_allocators_bad1.txt and corresponding slabinfo
> slab_allocators_after_bad1.txt and corresponding slabinfo
> slab_allocators_16_threads.txt and corresponding slabinfo
> slab_allocators_16_threads_1.txt and corresponding slabinfo
> slab_allocators_32_threads.txt and corresponding slabinfo
> slab_allocators_really_bad.txt and corresponding slabinfo.
>
>
> You will have to forgive my ignorance at this point, but I was looking
> through the slabinfo and slab_allocators, and noticed that size-4096
> does not show up in slab_allocators... I hope that is by design. You
> can see it growing into the gigabytes in the slabinfo files....
Argh. OK, I don't understand well enough how this works. Time to ask
someone, I guess....
--b.
>
>
>
> >
> > I think that debugging will hurt the server performance, so you won't
> > want to keep it turned on all the time.
> >
> > >
> > > Also, this is all with the SLAB cache option. SLUB crashes
> > everytime
> > > I use it under heavy load.
> >
> > Have you reported the SLUB bugs to lkml?
>
> No, I haven't yet. I didn't know for sure if I was doing something
> wrong, or if SLUB was the problem there. Since the failures, I had gone
> back to using SLAB anyway, so .... I probably should...
>
> >
> > --b.
> >
>
>
> Norman Weathers
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of J. Bruce Fields
> Sent: Wednesday, June 11, 2008 5:55 PM
> To: Weathers, Norman R.
> Cc: Jeff Layton; [email protected];
> [email protected]
> Subject: Re: CONFIG_DEBUG_SLAB_LEAK omits size-4096 and larger?
>
> On Wed, Jun 11, 2008 at 05:46:13PM -0500, Weathers, Norman R. wrote:
> > I will try and get it patched and retested, but it may be a
> day or two
> > before I can get back the information due to production jobs now
> > running. Once they finish up, I will get back with the info.
>
> Understood.
>
I was able to get my big user to cooperate and let me in to be able to
get the information that you were needing. The full output from the
/proc/slab_allocator file is at
http://www.shashi-weathers.net/linux/cluster/NFS_DEBUG_2 . The 16
thread case is very interesting. Also, there is a small txt file in the
directory that has some rpc errors, but I imagine the way that I am
running the box (oversubscribed threads) has more to do with the rpc
errors than anything else. For those of you wanting the gist of the
story, the size-4096 slab has the following very large allocation:
size-4096: 2 sys_init_module+0x140b/0x1980
size-4096: 1 __vmalloc_area_node+0x188/0x1b0
size-4096: 1 seq_read+0x1d9/0x2e0
size-4096: 1 slabstats_open+0x2b/0x80
size-4096: 5 vc_allocate+0x167/0x190
size-4096: 3 input_allocate_device+0x12/0x80
size-4096: 1 hid_add_field+0x122/0x290
size-4096: 9 reqsk_queue_alloc+0x5f/0xf0
size-4096: 1846825 __alloc_skb+0x7d/0x170
size-4096: 3 alloc_netdev+0x33/0xa0
size-4096: 10 neigh_sysctl_register+0x52/0x2b0
size-4096: 5 devinet_sysctl_register+0x28/0x110
size-4096: 1 pidmap_init+0x15/0x60
size-4096: 1 netlink_proto_init+0x44/0x190
size-4096: 1 ip_rt_init+0xfd/0x2f0
size-4096: 1 cipso_v4_init+0x13/0x70
size-4096: 3 journal_init_revoke+0xe7/0x270 [jbd]
size-4096: 3 journal_init_revoke+0x18a/0x270 [jbd]
size-4096: 2 journal_init_inode+0x84/0x150 [jbd]
size-4096: 2 bnx2_alloc_mem+0x18/0x1f0 [bnx2]
size-4096: 1 joydev_connect+0x53/0x390 [joydev]
size-4096: 13 kmem_alloc+0xb3/0x100 [xfs]
size-4096: 5 addrconf_sysctl_register+0x31/0x130 [ipv6]
size-4096: 7 rpc_clone_client+0x84/0x140 [sunrpc]
size-4096: 3 rpc_create+0x254/0x4d0 [sunrpc]
size-4096: 16 __svc_create_thread+0x53/0x1f0 [sunrpc]
size-4096: 16 __svc_create_thread+0x72/0x1f0 [sunrpc]
size-4096: 1 nfsd_racache_init+0x2e/0x140 [nfsd]
The big one seems to be the __alloc_skb. (This is with 16 threads, and
it says that we are using up somewhere between 12 and 14 GB of memory,
about 2 to 3 gig of that is disk cache). If I were to put anymore
threads out there, the server would become almost unresponsive (it was
bad enough as it was).
At the same time, I also noticed this:
skbuff_fclone_cache: 1842524 __alloc_skb+0x50/0x170
Don't know for sure if that is meaningful or not....
> > Thanks everyone for looking at this, by the way!
>
> And thanks for your persistence.
>
> --b.
>
Anytime. This is the part of the job that is fun (except for my
users...). Anyone can watch a system run, it's dealing with the unknown
that makes it interesting.
Norman Weathers
> >
> > >
> > >
> > > diff --git a/mm/slab.c b/mm/slab.c
> > > index 06236e4..b379e31 100644
> > > --- a/mm/slab.c
> > > +++ b/mm/slab.c
> > > @@ -2202,7 +2202,7 @@ kmem_cache_create (const char *name,
> > > size_t size, size_t align,
> > > * above the next power of two: caches with object
> > > sizes just above a
> > > * power of two have a significant amount of internal
> > > fragmentation.
> > > */
> > > - if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> > > + if (size < 8192 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> > > 2 *
> > > sizeof(unsigned long long)))
> > > flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
> > > if (!(flags & SLAB_DESTROY_BY_RCU))
> > >
> >
> >
> > Norman Weathers
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
I'm probably missing something fundamental--why doesn't
/proc/slab_allocators show any results for size-x where x >= 4096?
Someone's seeing a performance problem with the linux nfs server. One
of the symptoms is the "size-4096" slab cache seems to be out of
control. I assumed that meant that memory allocated by kmalloc() might
be leaking, so figured it might be interesting to turn on
CONFIG_DEBUG_SLAB_LEAK. As far as I can tell what that does is list
kmalloc() callers in /proc/slab_allocators. But that doesn't seem to be
showing any results for size-4096. Can anyone provide a clue?
Thanks!
--b.
On Wed, Jun 11, 2008 at 02:46:13PM -0400, bfields wrote:
> On Tue, Jun 10, 2008 at 05:12:31PM -0500, Weathers, Norman R. wrote:
> >
> >
> > > -----Original Message-----
> > > From: J. Bruce Fields [mailto:[email protected]]
> > > Sent: Tuesday, June 10, 2008 12:16 PM
> > > To: Weathers, Norman R.
> > > Cc: [email protected]
> > > Subject: Re: Problems with large number of clients and reads
> > >
> > > On Tue, Jun 10, 2008 at 09:30:18AM -0500, Weathers, Norman R. wrote:
> > > > Unfortunately, I cannot stop the clients (middle of long running
> > > > jobs). I might be able to test this soon. If I have the number of
> > > > threads high, yes I can reduce the number of threads and it
> > > appears to
> > > > lower some of the memory, but even with as little as three threads,
> > > > the memory usage climbs very high, just not as high as if there are
> > > > say 8 threads. When the memory usage climbs high, it can cause the
> > > > box to not respond over the network (ssh, rsh), and even be very
> > > > sluggish when I am connected over our serial console to the
> > > server(s).
> > > > This same scenario has been happening with kernels that I have tried
> > > > from 2.6.22.x on to the 2.6.25 series. The 2.6.25 series is
> > > > interesting in that I can push the same load from a box with the
> > > > 2.6.25 kernel and not have a load over .3 (with 3 threads), but with
> > > > the 2.6.22.x kernel, I have a load of over 3 when I hit the same
> > > > conditions.
> > >
> > > OK, I think what we want to do is turn on
> > > CONFIG_DEBUG_SLAB_LEAK. I've
> > > never used it before, but it looks like it will report which functions
> > > are allocating from each slab cache, which may be exactly what we need
> > > to know. So:
> > >
> > > 1. Install a kernel with both CONFIG_DEBUG_SLAB ("Debug slab
> > > memory allocations") and CONFIG_DEBUG_SLAB_LEAK ("Memory leak
> > > debugging") turned on. They're both under the "kernel hacking"
> > > section of the kernel config. (If you have a file
> > > /proc/slab_allocators, then you already have these turned on and
> > > you can skip this step.)
> > >
> > > 2. Do whatever you need to do to reproduce the problem.
> > >
> > > 3. Get a copy of /proc/slabinfo and /proc/slab_allocators.
> > >
> > > Then we can take a look at that and see if it sheds any light.
> >
> >
> > I have taken several snapshots of the /proc/slab_allocators and
> > /proc/slabinfo as requested, but since there is a lot of info in them,
> > and I didn't think anyone wanted to go cross-eyed reading the data in an
> > email, I have them up on a website:
> >
> > http://shashi-weathers.net/linux/cluster/NFS/
>
> Excellent.
>
> >
> > The order of data collection is:
> >
> > slab_allocators_bad1.txt and corresponding slabinfo
> > slab_allocators_after_bad1.txt and corresponding slabinfo
> > slab_allocators_16_threads.txt and corresponding slabinfo
> > slab_allocators_16_threads_1.txt and corresponding slabinfo
> > slab_allocators_32_threads.txt and corresponding slabinfo
> > slab_allocators_really_bad.txt and corresponding slabinfo.
> >
> >
> > You will have to forgive my ignorance at this point, but I was looking
> > through the slabinfo and slab_allocators, and noticed that size-4096
> > does not show up in slab_allocators... I hope that is by design. You
> > can see it growing into the gigabytes in the slabinfo files....
>
> Argh. OK, I don't understand well enough how this works. Time to ask
> someone, I guess....
>
> --b.
>
> >
> >
> >
> > >
> > > I think that debugging will hurt the server performance, so you won't
> > > want to keep it turned on all the time.
> > >
> > > >
> > > > Also, this is all with the SLAB cache option. SLUB crashes
> > > everytime
> > > > I use it under heavy load.
> > >
> > > Have you reported the SLUB bugs to lkml?
> >
> > No, I haven't yet. I didn't know for sure if I was doing something
> > wrong, or if SLUB was the problem there. Since the failures, I had gone
> > back to using SLAB anyway, so .... I probably should...
> >
> > >
> > > --b.
> > >
> >
> >
> > Norman Weathers
On Wed, 11 Jun 2008 15:52:22 -0400
"J. Bruce Fields" <[email protected]> wrote:
> I'm probably missing something fundamental--why doesn't
> /proc/slab_allocators show any results for size-x where x >= 4096?
>
> Someone's seeing a performance problem with the linux nfs server. One
> of the symptoms is the "size-4096" slab cache seems to be out of
> control. I assumed that meant that memory allocated by kmalloc() might
> be leaking, so figured it might be interesting to turn on
> CONFIG_DEBUG_SLAB_LEAK. As far as I can tell what that does is list
> kmalloc() callers in /proc/slab_allocators. But that doesn't seem to be
> showing any results for size-4096. Can anyone provide a clue?
> Thanks!
>
> --b.
>
Hmm...I've never used this, but in kmem_cache_alloc():
/*
* Enable redzoning and last user accounting, except for caches with
* large objects, if the increased size would increase the object size
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
2 * sizeof(unsigned long long)))
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
...looks like it specifically excludes some caches.
> On Wed, Jun 11, 2008 at 02:46:13PM -0400, bfields wrote:
> > On Tue, Jun 10, 2008 at 05:12:31PM -0500, Weathers, Norman R. wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: J. Bruce Fields [mailto:[email protected]]
> > > > Sent: Tuesday, June 10, 2008 12:16 PM
> > > > To: Weathers, Norman R.
> > > > Cc: [email protected]
> > > > Subject: Re: Problems with large number of clients and reads
> > > >
> > > > On Tue, Jun 10, 2008 at 09:30:18AM -0500, Weathers, Norman R. wrote:
> > > > > Unfortunately, I cannot stop the clients (middle of long running
> > > > > jobs). I might be able to test this soon. If I have the number of
> > > > > threads high, yes I can reduce the number of threads and it
> > > > appears to
> > > > > lower some of the memory, but even with as little as three threads,
> > > > > the memory usage climbs very high, just not as high as if there are
> > > > > say 8 threads. When the memory usage climbs high, it can cause the
> > > > > box to not respond over the network (ssh, rsh), and even be very
> > > > > sluggish when I am connected over our serial console to the
> > > > server(s).
> > > > > This same scenario has been happening with kernels that I have tried
> > > > > from 2.6.22.x on to the 2.6.25 series. The 2.6.25 series is
> > > > > interesting in that I can push the same load from a box with the
> > > > > 2.6.25 kernel and not have a load over .3 (with 3 threads), but with
> > > > > the 2.6.22.x kernel, I have a load of over 3 when I hit the same
> > > > > conditions.
> > > >
> > > > OK, I think what we want to do is turn on
> > > > CONFIG_DEBUG_SLAB_LEAK. I've
> > > > never used it before, but it looks like it will report which functions
> > > > are allocating from each slab cache, which may be exactly what we need
> > > > to know. So:
> > > >
> > > > 1. Install a kernel with both CONFIG_DEBUG_SLAB ("Debug slab
> > > > memory allocations") and CONFIG_DEBUG_SLAB_LEAK ("Memory leak
> > > > debugging") turned on. They're both under the "kernel hacking"
> > > > section of the kernel config. (If you have a file
> > > > /proc/slab_allocators, then you already have these turned on and
> > > > you can skip this step.)
> > > >
> > > > 2. Do whatever you need to do to reproduce the problem.
> > > >
> > > > 3. Get a copy of /proc/slabinfo and /proc/slab_allocators.
> > > >
> > > > Then we can take a look at that and see if it sheds any light.
> > >
> > >
> > > I have taken several snapshots of the /proc/slab_allocators and
> > > /proc/slabinfo as requested, but since there is a lot of info in them,
> > > and I didn't think anyone wanted to go cross-eyed reading the data in an
> > > email, I have them up on a website:
> > >
> > > http://shashi-weathers.net/linux/cluster/NFS/
> >
> > Excellent.
> >
> > >
> > > The order of data collection is:
> > >
> > > slab_allocators_bad1.txt and corresponding slabinfo
> > > slab_allocators_after_bad1.txt and corresponding slabinfo
> > > slab_allocators_16_threads.txt and corresponding slabinfo
> > > slab_allocators_16_threads_1.txt and corresponding slabinfo
> > > slab_allocators_32_threads.txt and corresponding slabinfo
> > > slab_allocators_really_bad.txt and corresponding slabinfo.
> > >
> > >
> > > You will have to forgive my ignorance at this point, but I was looking
> > > through the slabinfo and slab_allocators, and noticed that size-4096
> > > does not show up in slab_allocators... I hope that is by design. You
> > > can see it growing into the gigabytes in the slabinfo files....
> >
> > Argh. OK, I don't understand well enough how this works. Time to ask
> > someone, I guess....
> >
> > --b.
> >
> > >
> > >
> > >
> > > >
> > > > I think that debugging will hurt the server performance, so you won't
> > > > want to keep it turned on all the time.
> > > >
> > > > >
> > > > > Also, this is all with the SLAB cache option. SLUB crashes
> > > > everytime
> > > > > I use it under heavy load.
> > > >
> > > > Have you reported the SLUB bugs to lkml?
> > >
> > > No, I haven't yet. I didn't know for sure if I was doing something
> > > wrong, or if SLUB was the problem there. Since the failures, I had gone
> > > back to using SLAB anyway, so .... I probably should...
> > >
> > > >
> > > > --b.
> > > >
> > >
> > >
> > > Norman Weathers
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Jeff Layton <[email protected]>
On Wed, Jun 11, 2008 at 04:09:47PM -0400, Jeff Layton wrote:
> On Wed, 11 Jun 2008 15:52:22 -0400
> "J. Bruce Fields" <[email protected]> wrote:
>
> > I'm probably missing something fundamental--why doesn't
> > /proc/slab_allocators show any results for size-x where x >= 4096?
> >
> > Someone's seeing a performance problem with the linux nfs server. One
> > of the symptoms is the "size-4096" slab cache seems to be out of
> > control. I assumed that meant that memory allocated by kmalloc() might
> > be leaking, so figured it might be interesting to turn on
> > CONFIG_DEBUG_SLAB_LEAK. As far as I can tell what that does is list
> > kmalloc() callers in /proc/slab_allocators. But that doesn't seem to be
> > showing any results for size-4096. Can anyone provide a clue?
> > Thanks!
> >
> > --b.
> >
>
>
> Hmm...I've never used this, but in kmem_cache_alloc():
>
> /*
> * Enable redzoning and last user accounting, except for caches with
> * large objects, if the increased size would increase the object size
> * above the next power of two: caches with object sizes just above a
> * power of two have a significant amount of internal fragmentation.
> */
> if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> 2 * sizeof(unsigned long long)))
> flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
>
>
> ...looks like it specifically excludes some caches.
Ah, I missed that! I'm a little confused as to how those flags behavior
affect the collection of the leak debugging data, but I can verify that
the below does result in size-4096 showing up in /proc/slab_allocators;
hopefully there's no more negative result than the performance penalty.
Norman, do you think you could try applying this and then trying again?
--b.
diff --git a/mm/slab.c b/mm/slab.c
index 06236e4..b379e31 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -2202,7 +2202,7 @@ kmem_cache_create (const char *name, size_t size, size_t align,
* above the next power of two: caches with object sizes just above a
* power of two have a significant amount of internal fragmentation.
*/
- if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
+ if (size < 8192 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
2 * sizeof(unsigned long long)))
flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
if (!(flags & SLAB_DESTROY_BY_RCU))
> -----Original Message-----
> From: J. Bruce Fields [mailto:[email protected]]
> Sent: Wednesday, June 11, 2008 3:58 PM
> To: Jeff Layton
> Cc: [email protected]; [email protected];
> Weathers, Norman R.
> Subject: Re: CONFIG_DEBUG_SLAB_LEAK omits size-4096 and larger?
>
> On Wed, Jun 11, 2008 at 04:09:47PM -0400, Jeff Layton wrote:
> > On Wed, 11 Jun 2008 15:52:22 -0400
> > "J. Bruce Fields" <[email protected]> wrote:
> >
> > > I'm probably missing something fundamental--why doesn't
> > > /proc/slab_allocators show any results for size-x where x >= 4096?
> > >
> > > Someone's seeing a performance problem with the linux nfs
> server. One
> > > of the symptoms is the "size-4096" slab cache seems to be out of
> > > control. I assumed that meant that memory allocated by
> kmalloc() might
> > > be leaking, so figured it might be interesting to turn on
> > > CONFIG_DEBUG_SLAB_LEAK. As far as I can tell what that
> does is list
> > > kmalloc() callers in /proc/slab_allocators. But that
> doesn't seem to be
> > > showing any results for size-4096. Can anyone provide a clue?
> > > Thanks!
> > >
> > > --b.
> > >
> >
> >
> > Hmm...I've never used this, but in kmem_cache_alloc():
> >
> > /*
> > * Enable redzoning and last user accounting,
> except for caches with
> > * large objects, if the increased size would
> increase the object size
> > * above the next power of two: caches with object
> sizes just above a
> > * power of two have a significant amount of
> internal fragmentation.
> > */
> > if (size < 4096 || fls(size - 1) == fls(size-1 +
> REDZONE_ALIGN +
> > 2 *
> sizeof(unsigned long long)))
> > flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
> >
> >
> > ...looks like it specifically excludes some caches.
>
> Ah, I missed that! I'm a little confused as to how those
> flags behavior
> affect the collection of the leak debugging data, but I can
> verify that
> the below does result in size-4096 showing up in
> /proc/slab_allocators;
> hopefully there's no more negative result than the
> performance penalty.
>
> Norman, do you think you could try applying this and then
> trying again?
>
> --b.
I will try and get it patched and retested, but it may be a day or two
before I can get back the information due to production jobs now
running. Once they finish up, I will get back with the info.
Thanks everyone for looking at this, by the way!
>
>
> diff --git a/mm/slab.c b/mm/slab.c
> index 06236e4..b379e31 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -2202,7 +2202,7 @@ kmem_cache_create (const char *name,
> size_t size, size_t align,
> * above the next power of two: caches with object
> sizes just above a
> * power of two have a significant amount of internal
> fragmentation.
> */
> - if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> + if (size < 8192 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> 2 *
> sizeof(unsigned long long)))
> flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
> if (!(flags & SLAB_DESTROY_BY_RCU))
>
Norman Weathers
On Wed, Jun 11, 2008 at 05:46:13PM -0500, Weathers, Norman R. wrote:
> I will try and get it patched and retested, but it may be a day or two
> before I can get back the information due to production jobs now
> running. Once they finish up, I will get back with the info.
Understood.
> Thanks everyone for looking at this, by the way!
And thanks for your persistence.
--b.
>
> >
> >
> > diff --git a/mm/slab.c b/mm/slab.c
> > index 06236e4..b379e31 100644
> > --- a/mm/slab.c
> > +++ b/mm/slab.c
> > @@ -2202,7 +2202,7 @@ kmem_cache_create (const char *name,
> > size_t size, size_t align,
> > * above the next power of two: caches with object
> > sizes just above a
> > * power of two have a significant amount of internal
> > fragmentation.
> > */
> > - if (size < 4096 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> > + if (size < 8192 || fls(size - 1) == fls(size-1 + REDZONE_ALIGN +
> > 2 *
> > sizeof(unsigned long long)))
> > flags |= SLAB_RED_ZONE | SLAB_STORE_USER;
> > if (!(flags & SLAB_DESTROY_BY_RCU))
> >
>
>
> Norman Weathers