On Fri, 12 Dec 2008 01:22:32 +0300 Yuri Tikhonov <y...@emcraft.com> wrote:
> > so how about avoiding the nasty ifdefs and doing > > I'm OK with the approach below, but, leading resulting to the same, > this involves some overhead to the code where there was no this > overhead before this patch: e.g. your implementation is finally boils > down to ~5 times more processor instructions than there were before, > plus operations with stack for the 'm' variable. > > On the other hand, my approach with nasty (I agree) ifdefs doesn't > lead to overheads to the code which does not need this: i.e. the most > common situation of small PAGE_SIZEs. Big PAGE_SIZE is the exception, > so I believe that the more common cases should not suffer because of > this. yes, but... > > --- a/kernel/fork.c~fork_init-fix-division-by-zero > > +++ a/kernel/fork.c > > @@ -69,6 +69,7 @@ > > #include <asm/mmu_context.h> > > #include <asm/cacheflush.h> > > #include <asm/tlbflush.h> > > +#include <asm/div64.h> > > > > /* > > * Protected counters by write_lock_irq(&tasklist_lock) > > @@ -185,10 +186,15 @@ void __init fork_init(unsigned long memp This is __init code and it gets thrown away after bootup. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
