> 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 that is so bad. Suboptimal readahead somewhere is the smallest of your problems. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- From: Nick Piggin <nickpiggin@yahoo.com.au>
- Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- References:
- [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- From: Eric Dumazet <dada1@cosmosbay.com>
- Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- From: Andi Kleen <ak@suse.de>
- Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- From: Nick Piggin <nickpiggin@yahoo.com.au>
- [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- Prev by Date: [PATCH] DVB: lgdt330x check callback fix
- Next by Date: Re: sched_yield() makes OpenLDAP slow
- Previous by thread: Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- Next by thread: Re: [PATCH] struct file cleanup : the very large file_ra_state is now allocated only on demand.
- Index(es):
