Messages in this thread | | | Date | Thu, 28 Jul 2005 19:34:00 +1000 | From | Nick Piggin <> | Subject | Re: Add prefetch switch stack hook in scheduler function |
| |
Ingo Molnar wrote: > * Nick Piggin <nickpiggin@yahoo.com.au> wrote: > >
>>>such as? >> >>Not sure. thread_info? Maybe next->timestamp or some other fields in >>next, something in next->mm? > > > next->thread_info we could and should prefetch - but from the generic > scheduler code (see the patch i just sent). >
Right. We're always testing the TIF_NEED_RESCHED field after the switch.
> i'm not sure what you mean by prefetching next->timestamp, it's an > inline field to 'next', in the first cacheline of it, which we've > already used so it's present. (If you mean the value of next->timestamp, > that has no address meaning at all so would lead to unpredictable > results on some arches.) >
No, I meant the cacheline holding the field of course. I guess I could have looked for a field further down, but even so, ->timestamp might be 96 bytes into the structure on a 64-bit arch, which may or may not be the first cacheline... but you get the idea.
> next->mm we might want to prefetch, but it's probably not worth it > because we are referencing it too soon, in context_switch(). (while the > kernel stack itself wont be referenced until the full context-switch is > done) But might be worth trying - but even then, it should be done from > the generic code, like the thread_info and kernel-stack prefetching. > > >>I didn't really have a concrete example, but in the interests of being >>future proof... > > > i'd like to keep generic bits in generic code, and only move things to > per-arch include files if absolutely necessary. next->mm is generic. >
Yeah, then a specific field _within_ next->mm or thread_info may want to be fetched. In short, I don't see any argument why we shouldn't call the function prefetch_task().
Secondly, I don't really like your prefetch(kernel_stack()) function because it doesn't really give architectures enough control over exactly what cachelines they get in memory.
prefetching and memory access patterns of all this stuff are fairly architecture specific. I see nothing wrong with having a prefetch_task() call. (Although I agree things like thread_info->flags and next->mm can be done in generic code).
Nick
-- SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
- 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/
| |