On Mon, 17 Apr 2006, Steven Rostedt wrote: > So now we can focus on a better solution. Could you have a look at Kiran's work? Maybe one result of your work could be that the existing indirection for alloc_percpu could be avoided? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] 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 00/05] robust per_cpu allocation for modules
- From: Steven Rostedt <[email protected]>
- Re: [PATCH 00/05] robust per_cpu allocation for modules
- References:
- [PATCH 00/05] robust per_cpu allocation for modules
- From: Steven Rostedt <[email protected]>
- Re: [PATCH 00/05] robust per_cpu allocation for modules
- From: Nick Piggin <[email protected]>
- Re: [PATCH 00/05] robust per_cpu allocation for modules
- From: Christoph Lameter <[email protected]>
- Re: [PATCH 00/05] robust per_cpu allocation for modules
- From: Ravikiran G Thirumalai <[email protected]>
- Re: [PATCH 00/05] robust per_cpu allocation for modules
- From: Steven Rostedt <[email protected]>
- [PATCH 00/05] robust per_cpu allocation for modules
- Prev by Date: 2.6.16.1 & D state processes
- Next by Date: migration_entry_wait: Use the pte lock instead of the anon_vma lock.
- Previous by thread: Re: [PATCH 00/05] robust per_cpu allocation for modules
- Next by thread: Re: [PATCH 00/05] robust per_cpu allocation for modules
- Index(es):
 |