From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 09:14:47 +0200
> After reading your suggestions, I understand we still need two slabs.
> One (filp_cachep) without the readahead data, the other one
> (filp_ra_cachep) with it.
Correct.
> static inline struct file_ra_state *get_ra_sta
David S. Miller a écrit :
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 03:05:25 +0200
I would just set the ra pointer to a single global structure if the
allocation fails. Then you can avoid all the other checks. It will
slow down things and trash some state, but not fail and no
object size is 10*sizeof(long), so alignment would loose
6*sizeof(long) bytes for each object.
[PATCH]
* struct file cleanup : the very large file_ra_state is now allocated only on demand,
using a dedicated "file_ra" slab.
64bits machines handling lot of sockets can sa
Andi Kleen wrote:
You don't want to always have bad performance though, so you
could attempt to allocate if either the pointer is null _or_ it
points to the global structure?
Remember it's after a GFP_KERNEL OOM. If that fails most likely
you have deadlocked somewhere else already because Lin
> You don't want to always have bad performance though, so you
> could attempt to allocate if either the pointer is null _or_ it
> points to the global structure?
Remember it's after a GFP_KERNEL OOM. If that fails most likely
you have deadlocked somewhere else already because Linux's handling
of
Andi Kleen wrote:
I would just set the ra pointer to a single global structure if the allocation
fails. Then you can avoid all the other checks. It will slow down
things and trash some state, but not fail and nobody should expect good
performance after out of memory anyways. The only check sti
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 03:05:25 +0200
> I would just set the ra pointer to a single global structure if the
> allocation fails. Then you can avoid all the other checks. It will
> slow down things and trash some state, but not fail and nobody
> should expect goo
ood.
>
> I also chose not to align "file_ra" slab on SLAB_HWCACHE_ALIGN because the
> object size is 10*sizeof(long), so alignment would loose
> 6*sizeof(long) bytes for each object.
>
>
> [PATCH]
>
> * struct file cleanup : the very large file_ra_state is
On Thu, Aug 18, 2005 at 02:40:46AM +0200, Eric Dumazet wrote:
> Andi Kleen a ?crit :
>
> >
> >>(because of the insane struct file_ra_state f_ra. I wish this structure
> >>were dynamically allocated only for files that really use it)
> >
> >
> >How about you submit a patch for that instead?
> >
>
s for each object.
[PATCH]
* struct file cleanup : the very large file_ra_state is now allocated only on demand,
using a dedicated "file_ra" slab.
64bits machines handling lot of sockets can save about 72 bytes per
file.
* private_data : The field is moved close to f_count and f_
10 matches
Mail list logo
