Re: filp usage when cpu busy

2007-11-01 Thread bc Wong
Nick Piggin wrote: On Thursday 01 November 2007 12:56, bc Wong (chimwong) wrote: Hi, With 2.6.16 x86_64 on a 4 core machine, I noticed that the filp usage (according to /proc/slabinfo) shoots up and keeps on increasing sharply when one of the CPUs is (1) locked up, or (2) very busy doing a lot

Re: filp usage when cpu busy

2007-11-01 Thread bc Wong
Nick Piggin wrote: On Thursday 01 November 2007 12:56, bc Wong (chimwong) wrote: Hi, With 2.6.16 x86_64 on a 4 core machine, I noticed that the filp usage (according to /proc/slabinfo) shoots up and keeps on increasing sharply when one of the CPUs is (1) locked up, or (2) very busy doing a lot

Re: filp usage when cpu busy

2007-10-31 Thread Nick Piggin
On Thursday 01 November 2007 12:56, bc Wong (chimwong) wrote: > Hi, > > With 2.6.16 x86_64 on a 4 core machine, I noticed > that the filp usage (according to /proc/slabinfo) > shoots up and keeps on increasing sharply when one > of the CPUs is (1) locked up, or (2) very busy > doing a lot of

filp usage when cpu busy

2007-10-31 Thread bc Wong (chimwong)
Hi, With 2.6.16 x86_64 on a 4 core machine, I noticed that the filp usage (according to /proc/slabinfo) shoots up and keeps on increasing sharply when one of the CPUs is (1) locked up, or (2) very busy doing a lot of printk()'s with KERN_EMERG. In the case of (1), it's permanent until it runs

filp usage when cpu busy

2007-10-31 Thread bc Wong (chimwong)
Hi, With 2.6.16 x86_64 on a 4 core machine, I noticed that the filp usage (according to /proc/slabinfo) shoots up and keeps on increasing sharply when one of the CPUs is (1) locked up, or (2) very busy doing a lot of printk()'s with KERN_EMERG. In the case of (1), it's permanent until it runs

Re: filp usage when cpu busy

2007-10-31 Thread Nick Piggin
On Thursday 01 November 2007 12:56, bc Wong (chimwong) wrote: Hi, With 2.6.16 x86_64 on a 4 core machine, I noticed that the filp usage (according to /proc/slabinfo) shoots up and keeps on increasing sharply when one of the CPUs is (1) locked up, or (2) very busy doing a lot of printk()'s