* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I think this pretty clearly points out the need for some arch-generic
> infrastructure in Linux. An awful lot of arch hooks are for one or
> two architectures with some peculiarities, and the other 90% of the
> implementations are identical.
>
> include/asm-alpha/mmu_context.h |6 ++
> include/asm-arm/mmu_context.h |6 ++
> include/asm-arm26/mmu_context.h |6 ++
> include/asm-cris/mmu_context.h |6 ++
> include/asm-frv/mmu_context.h |6 ++
> include/asm-h8300/mmu_context.h
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> code like that always makes me think of duffs-device
> http://www.lysator.liu.se/c/duffs-device.html
>
> although it might be that the compiler generates better code from the
> current incarnation; just my .02 ;-)
yeah, will do that. First wanted
* Russell King <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 29, 2005 at 10:28:26AM +0200, Ingo Molnar wrote:
> > @@ -2872,10 +2878,10 @@ go_idle:
> > /*
> > * Prefetch (at least) a cacheline below the current
> > * kernel stack (in expectation of any new task touching
> > -* the sta
> -
> unroll prefetch_range() loops manually.
>
> Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
>
> include/linux/prefetch.h | 31 +--
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
> Index: linux/include/linux/prefetch.h
>
On Fri, Jul 29, 2005 at 10:28:26AM +0200, Ingo Molnar wrote:
> @@ -2872,10 +2878,10 @@ go_idle:
> /*
>* Prefetch (at least) a cacheline below the current
>* kernel stack (in expectation of any new task touching
> - * the stack at least minimally), and a cacheline above
>
Ingo Molnar wrote on Friday, July 29, 2005 1:36 AM
> * Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> > It generate slight different code because previous patch asks for a little
> > over 5 cache lines worth of bytes and it always go to the for loop.
>
> ok - fix below. But i'm not that sure we want
* Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Please test that len is a constant, or else the inlining is too large
> for the non constant case.
yeah. fix below.
Ingo
-
noticed by Eric Dumazet: unrolling should be dependent on a constant
length, otherwise inlining gets too large.
S
* Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote on Friday, July 29, 2005 12:07 AM
> > the patch below unrolls the prefetch_range() loop manually, for up to 5
> > cachelines prefetched. This patch, ontop of the 4 previous patches,
> > should generate similar code to the assembly
Ingo Molnar wrote on Friday, July 29, 2005 12:07 AM
> the patch below unrolls the prefetch_range() loop manually, for up to 5
> cachelines prefetched. This patch, ontop of the 4 previous patches,
> should generate similar code to the assembly code in your original
> patch. The full patch-series
Ingo Molnar a écrit :
unroll prefetch_range() loops manually.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
include/linux/prefetch.h | 31 +--
1 files changed, 29 insertions(+), 2 deletions(-)
Index: linux/include/linux/prefetch.h
=
* Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> On ia64, we have two kernel stacks, one for outgoing task, and one for
> incoming task. for outgoing task, we haven't called switch_to() yet.
> So the switch stack structure for 'current' will be allocated
> immediately below current 'sp' pointer
Keith Owens wrote on Friday, July 29, 2005 12:38 AM
> BTW, for ia64 you may as well prefetch pt_regs, that is also quite
> large.
>
> #define MIN_KERNEL_STACK_FOOTPRINT (IA64_SWITCH_STACK_SIZE +
> IA64_PT_REGS_SIZE)
This has to be carefully done, because you really don't want to overwhelm
number
Keith Owens wrote on Friday, July 29, 2005 12:46 AM
> On Fri, 29 Jul 2005 00:22:43 -0700,
> "Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
> >On ia64, we have two kernel stacks, one for outgoing task, and one for
> >incoming task. for outgoing task, we haven't called switch_to() yet.
> >So the swit
On Fri, 29 Jul 2005 00:22:43 -0700,
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>On ia64, we have two kernel stacks, one for outgoing task, and one for
>incoming task. for outgoing task, we haven't called switch_to() yet.
>So the switch stack structure for 'current' will be allocated immediately
On Fri, 29 Jul 2005 09:04:48 +0200,
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>ok, how about the additional patch below? Does this do the trick on
>ia64? It makes complete sense on every architecture to prefetch from
>below the current kernel stack, in the expectation of the next task
>touching th
Ingo Molnar wrote on Friday, July 29, 2005 12:05 AM
> --- linux.orig/kernel/sched.c
> +++ linux/kernel/sched.c
> @@ -2869,7 +2869,14 @@ go_idle:
>* its thread_info, its kernel stack and mm:
>*/
> prefetch(next->thread_info);
> - prefetch(kernel_stack(next));
> + /*
> +
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Sorry, this is not enough. Switch stack on ia64 is 528 bytes. We
> > need to prefetch 5 lines. It probably should use prefetch_range().
>
> ok, how about the additional patch below? Does this do the trick on
> ia64? It makes complete sense on e
* Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
> > i.e. like the patch below. Boot-tested on x86. x86, x64 and ia64 have a
> > real kernel_stack() implementation, the other architectures all return
> > 'next'. (I've also cleaned up a couple of other things in the
> > prefetch-next area, see the
> i.e. like the patch below. Boot-tested on x86. x86, x64 and ia64 have a
> real kernel_stack() implementation, the other architectures all return
> 'next'. (I've also cleaned up a couple of other things in the
> prefetch-next area, see the changelog below.)
>
> Ken, would this patch generate a
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
[...]
prefetch_area(void *first_addr, void *last_addr)
(or as addr,len)
Yep. We have prefetch_range.
Yeah, then a specific field _within_ next->mm or thread_info may want
to be fetched. In short, I don't see any argu
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >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
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> 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).
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 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 -
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>Just a minor point, I agree with David: I'd like it to be called
> >>prefetch_task(), because some architecture may want to prefetch other
> >>memory.
> >
> >such as?
>
> Not sure. thread_info? Maybe next->timestamp or some other fields in
> next,
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [...] If yes then we want to have something like:
>
> prefetch(kernel_stack(next));
>
> to make it more generic. By default kernel_stack(next) could be
> next->thread_info (to make sure we prefetch something real). On e.g.
> x86/x64, kernel_sta
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
No, they can be up to 30K apart. See include/asm-ia64/ptrace.h.
thread_info is at ~0xda0, depending on the config. The switch_stack
can be as high as 0x7bd0 in the kernel stack, depending on why the task
is sleeping.
Just a minor
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> >No, they can be up to 30K apart. See include/asm-ia64/ptrace.h.
> >thread_info is at ~0xda0, depending on the config. The switch_stack
> >can be as high as 0x7bd0 in the kernel stack, depending on why the task
> >is sleeping.
> >
>
> Just a minor poi
Keith Owens wrote:
On Thu, 28 Jul 2005 09:41:18 +0200,
Ingo Molnar <[EMAIL PROTECTED]> wrote:
i'm wondering, is the switch_stack at the same/similar place as
next->thread_info? If yes then we could simply do a
prefetch(next->thread_info).
No, they can be up to 30K apart. See include/asm-ia
On Thu, 28 Jul 2005 09:41:18 +0200,
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>* david mosberger <[EMAIL PROTECTED]> wrote:
>
>> Also, should this be called prefetch_stack() or perhaps even just
>> prefetch_task()? Not every architecture defines a switch_stack
>> structure.
>
>yeah. I'd too suggest
* Keith Owens wrote:
> >yeah. I'd too suggest to call it prefetch_stack(), and not make it a
> >macro & hook but something defined on all arches, with for now only ia64
> >having any real code in the inline function.
> >
> >i'm wondering, is the switch_stack at the same/similar place as
> >next-
* david mosberger <[EMAIL PROTECTED]> wrote:
> Also, should this be called prefetch_stack() or perhaps even just
> prefetch_task()? Not every architecture defines a switch_stack
> structure.
yeah. I'd too suggest to call it prefetch_stack(), and not make it a
macro & hook but something defin
Also, should this be called prefetch_stack() or perhaps even just
prefetch_task()? Not every architecture defines a switch_stack
structure.
--david
--
Mosberger Consulting LLC, voice/fax: 510-744-9372,
http://www.mosberger-consulting.com/
35706 Runckel Lane, Fremont, CA 94536
On 7/27/05, And
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>
> +#ifdef ARCH_HAS_PREFETCH_SWITCH_STACK
> +extern void prefetch_switch_stack(struct task_struct*);
> +#else
> +#define prefetch_switch_stack(task) do { } while (0)
> +#endif
It is better to use
static inline void prefetch_switch_stack(struct tas
34 matches
Mail list logo
