Andrew Morton wrote:
> On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>
>
>>The out_of_memory() function and SysRq-M handler call
>>show_mem() to show the current memory usage state.
>>
>>This is also helpful to see which slabs are the largest
>>in the system.
>>
Andrew Morton wrote:
On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for
On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> The out_of_memory() function and SysRq-M handler call
> show_mem() to show the current memory usage state.
>
> This is also helpful to see which slabs are the largest
> in the system.
>
> Thanks Pekka for good idea
On Wed, 18 Apr 2007 11:13:01 +0400 Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to
On Wed, 18 Apr 2007 09:17:19 +0300 (EEST)
Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> On Tue, 17 Apr 2007, Eric Dumazet wrote:
> > This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
> > or else you defeat NUMA optimizations if touching a field in kmem_cache
> > at
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed
Pekka Enberg wrote:
> On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>> The out_of_memory() function and SysRq-M handler call
>> show_mem() to show the current memory usage state.
>
> I am still somewhat unhappy about the spinlock, but I don't really
What's wrong with the spinlock? It
Dave Hansen wrote:
> On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
>> +#define SHOW_TOP_SLABS 10
>
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define TOP_NR_SLABS_TO_SHOW 10
>
> or
>
On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
have a better suggestion either. Other than that, looks good to me.
On Tue, 17 Apr 2007, Eric Dumazet wrote:
> This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
> or else you defeat NUMA optimizations if touching a field in kmem_cache
> at kmem_getpages()/kmem_freepages() time.
We already touch ->flags, ->gfpflags, and ->gfporder in
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
> > +#define SHOW_TOP_SLABS 10
On Tue, 17 Apr 2007, Dave Hansen wrote:
> Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
> I show the top slabs?"
>
> This might be a bit more clear:
>
> #define
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
On Tue, 17 Apr 2007, Dave Hansen wrote:
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
On Tue, 17 Apr 2007, Eric Dumazet wrote:
This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
or else you defeat NUMA optimizations if touching a field in kmem_cache
at kmem_getpages()/kmem_freepages() time.
We already touch -flags, -gfpflags, and -gfporder in
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
have a better suggestion either. Other than that, looks good to me.
Dave Hansen wrote:
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
or
#define
Pekka Enberg wrote:
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
I am still somewhat unhappy about the spinlock, but I don't really
What's wrong with the spinlock? It exists
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed
On Wed, 18 Apr 2007 09:17:19 +0300 (EEST)
Pekka J Enberg [EMAIL PROTECTED] wrote:
On Tue, 17 Apr 2007, Eric Dumazet wrote:
This nr_pages should be in struct kmem_list3, not in struct kmem_cache,
or else you defeat NUMA optimizations if touching a field in kmem_cache
at
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
> +#define SHOW_TOP_SLABS 10
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. "Should
I show the top slabs?"
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
or
#define NR_SLABS_TO_SHOW 10
-- Dave
-
To
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed
On Tue, 17 Apr 2007 16:22:48 +0300
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
> > +static unsigned long get_cache_size(struct kmem_cache *cachep)
> > +{
> > + unsigned long slabs;
> > + struct kmem_list3 *l3;
> > +
Hi Pavel,
At some point in time, I wrote:
> > So, now we have two locks protecting cache_chain? Please explain why
> > you can't use the mutex.
On Tue, 17 Apr 2007, Pavel Emelianov wrote:
> Because OOM can actually happen with this mutex locked. For example
> kmem_cache_create() locks it and
Pekka J Enberg wrote:
> Hi Pavel,
>
> At some point in time, I wrote:
>>> So, now we have two locks protecting cache_chain? Please explain why
>>> you can't use the mutex.
>
> On Tue, 17 Apr 2007, Pavel Emelianov wrote:
>> Because OOM can actually happen with this mutex locked. For example
>>
Pekka Enberg wrote:
> Hi,
>
> On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
>> The out_of_memory() function and SysRq-M handler call
>> show_mem() to show the current memory usage state.
>>
>> This is also helpful to see which slabs are the largest
>> in the system.
>
> Makes sense.
Hi,
On 4/17/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Makes sense.
On 4/17/07, Pavel Emelianov <[EMAIL
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Signed-off-by: Pavel Emelianov <[EMAIL PROTECTED]>
Signed-off-by: Kirill Korotaev <[EMAIL PROTECTED]>
---
diff --git
Pekka Enberg wrote:
Hi,
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Makes sense.
Thanks! :)
On
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Thanks Pekka for good idea of how to make it better.
The nr_pages is stored on kmem_list3 because:
1. as Eric pointed
Hi,
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Makes sense.
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED]
On Tue, 17 Apr 2007 16:22:48 +0300
Pekka Enberg [EMAIL PROTECTED] wrote:
Hi,
On 4/17/07, Pavel Emelianov [EMAIL PROTECTED] wrote:
+static unsigned long get_cache_size(struct kmem_cache *cachep)
+{
+ unsigned long slabs;
+ struct kmem_list3 *l3;
+ struct list_head
Pekka J Enberg wrote:
Hi Pavel,
At some point in time, I wrote:
So, now we have two locks protecting cache_chain? Please explain why
you can't use the mutex.
On Tue, 17 Apr 2007, Pavel Emelianov wrote:
Because OOM can actually happen with this mutex locked. For example
The out_of_memory() function and SysRq-M handler call
show_mem() to show the current memory usage state.
This is also helpful to see which slabs are the largest
in the system.
Signed-off-by: Pavel Emelianov [EMAIL PROTECTED]
Signed-off-by: Kirill Korotaev [EMAIL PROTECTED]
---
diff --git
Hi Pavel,
At some point in time, I wrote:
So, now we have two locks protecting cache_chain? Please explain why
you can't use the mutex.
On Tue, 17 Apr 2007, Pavel Emelianov wrote:
Because OOM can actually happen with this mutex locked. For example
kmem_cache_create() locks it and calls
On Tue, 2007-04-17 at 19:34 +0400, Pavel Emelianov wrote:
+#define SHOW_TOP_SLABS 10
Real minor nit on this one: SHOW_TOP_SLABS sounds like a bool. Should
I show the top slabs?
This might be a bit more clear:
#define TOP_NR_SLABS_TO_SHOW 10
or
#define NR_SLABS_TO_SHOW 10
-- Dave
-
To
34 matches
Mail list logo