zeroing pages in the idle task?

zeroing pages in the idle task?

[Michel Lanners]

Hi all,

I've come across a 'forgotten' feature of the PPC kernels: namely
zeroing pages 'in advance' in the idle task.

It's a feature Cort implemented some time ago, but which is disabled by
default. I've tried to enable it:

[root@piglet ~]# echo 1 > /proc/sys/kernel/zero-paged

and it seems to work OK:

(this is after system boot, no apps started yet except 3 xterms)

[mlan@piglet ~]$ cat /proc/cpuinfo
processor       : 0
cpu             : 750
temperature     : 0 C
clock           : 195MHz
                  ^^^^^^
(by the way, this is wrong. Anybody with a fix?)

revision        : 2.2
bogomips        : 575.08
zero pages      : total 264 (1056Kb) current: 96 (384Kb) hits: 168/255 (65%)
machine         : Power Macintosh
motherboard     : AAPL,7500 MacRISC
memory          : 112MB
pmac-generation : OldWorld

So, a few questions:

- is there any problem with using this feature?

- if not, would it be a good idea to enable it by default?

- or, would it be better to add it to rc.sysinit, leaving it to each
  distribution whether to enable it or not?

I've not benchmarked anything (how would one do that?); but it seems to
me it's a no-cost optimisation. Even if there's little advantage, since
it's for free...

Comments?

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Paul Mackerras]

Michel Lanners writes:

> clock           : 195MHz
>                   ^^^^^^
> (by the way, this is wrong. Anybody with a fix?)

I'm pretty sure that this is the number that OF is telling us, so if
it's wrong, blame OF.  You don't have a G3 upgrade card in an older
machine perhaps?

Since the only use of this number is for oohs and aahs, there's not a
lot of motivation to try and work out if OF is wrong and work out the
correct number.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Michel Lanners]

Hi Paul,

On  13 Sep, this message from Paul Mackerras echoed through cyberspace:
> Michel Lanners writes:
>
>> clock           : 195MHz
>>                   ^^^^^^
>> (by the way, this is wrong. Anybody with a fix?)
>
> I'm pretty sure that this is the number that OF is telling us, so if
> it's wrong, blame OF.  You don't have a G3 upgrade card in an older
> machine perhaps?

Yes, right. And I've seen OF report this before, and indeed, this info
comes out of OF.

> Since the only use of this number is for oohs and aahs, there's not a
> lot of motivation to try and work out if OF is wrong and work out the
> correct number.

Somebody might want to unify and come up with a routine that can
calculate clock frequency across all PPC machines. I don't know if
something like this can be done with only the processor, and no
motherboard hardware support...

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Takashi Oe]

Hi,

On Wed, 13 Sep 2000, Paul Mackerras wrote:

> Michel Lanners writes:
>
> > clock           : 195MHz
> >                   ^^^^^^
> > (by the way, this is wrong. Anybody with a fix?)
>
> I'm pretty sure that this is the number that OF is telling us, so if
> it's wrong, blame OF.  You don't have a G3 upgrade card in an older
> machine perhaps?
>
> Since the only use of this number is for oohs and aahs, there's not a
> lot of motivation to try and work out if OF is wrong and work out the
> correct number.

Could you possibly tell me how one might implement this?  That is: how one
would measure/calculate this.  On NuBus, there is no OF, so I'd like to
implement.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Benjamin Herrenschmidt]

>> I'm pretty sure that this is the number that OF is telling us, so if
>> it's wrong, blame OF.  You don't have a G3 upgrade card in an older
>> machine perhaps?
>
>Yes, right. And I've seen OF report this before, and indeed, this info
>comes out of OF.

I remember seeing various "fixes" done by the Apple code in Darwin to
correct the bogus values returned by OF on some machines.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[David A. Gatwood]

On Wed, 13 Sep 2000, Takashi Oe wrote:

> > Since the only use of this number is for oohs and aahs, there's not a
> > lot of motivation to try and work out if OF is wrong and work out the
> > correct number.
>
> Could you possibly tell me how one might implement this?  That is: how one
> would measure/calculate this.  On NuBus, there is no OF, so I'd like to
> implement.

Ask the guys at Newer Tech for their Clockometer sources.  I don't know if
they'd be willing to open-source them, but it's worth a shot.  As I
understand it, their program does just what you're looking for.


Later,
David

---------------------------------------------------------------------
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Geert Uytterhoeven]

On Wed, 13 Sep 2000, David A. Gatwood wrote:
> On Wed, 13 Sep 2000, Takashi Oe wrote:
> > > Since the only use of this number is for oohs and aahs, there's not a
> > > lot of motivation to try and work out if OF is wrong and work out the
> > > correct number.
> >
> > Could you possibly tell me how one might implement this?  That is: how one
> > would measure/calculate this.  On NuBus, there is no OF, so I'd like to
> > implement.
>
> Ask the guys at Newer Tech for their Clockometer sources.  I don't know if
> they'd be willing to open-source them, but it's worth a shot.  As I
> understand it, their program does just what you're looking for.

On the m68k, we have some code to guestimate the CPU clock based on the
BogoMIPS (see get_cpuinfo() in arch/m68k/kernel/setup.c). Since we didn't care
about the overhead incurred by interrupt processing, it's not that accurate
though (I get 24.8 MHz on my 25 MHz 68040).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Michel Lanners]

All, and especially Paul/Cort,

To come back to my original question...

On  12 Sep, this message from mlan echoed through cyberspace:
> I've come across a 'forgotten' feature of the PPC kernels: namely
> zeroing pages 'in advance' in the idle task.
>
> It's a feature Cort implemented some time ago, but which is disabled by
> default.
[snip]
> So, a few questions:
>
> - is there any problem with using this feature?

I didn't have any, but that's only my box then....

> - if not, would it be a good idea to enable it by default?

What do you think, Paul, Cort?

> - or, would it be better to add it to rc.sysinit, leaving it to each
>   distribution whether to enable it or not?

Maybe enabling it by default would be a good choice? It can always be
disabled...

I'll post a patch on sourceforge.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Cort Dougan]

I missed a lot of this thread, this is the first message I picked up on.

} To come back to my original question...

It's a dead loss on SMP, but it can be just run on UP machines.  The main
problem was I didn't have enough time to finish it and didn't want to leave
something running in the idle task that I hadn't finished studying the
effect of.

I really wanted to push it up to the freelist since I don't think it's a
PPC-only optimization.  I never bothered trying to push it since at that
point the tree was moving to the stable point and wasn't going to be
changing that radically soon.

} > - is there any problem with using this feature?
}
} I didn't have any, but that's only my box then....

Not without a lot of study and testing.  I haven't touched the code in a
long time...

} What do you think, Paul, Cort?

It's not a matter of turning it on - it's a matter of making it work again
and testing it.

} Maybe enabling it by default would be a good choice? It can always be
} disabled...
}
} I'll post a patch on sourceforge.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Paul Mackerras]

Michel Lanners writes:

> > - if not, would it be a good idea to enable it by default?
>
> What do you think, Paul, Cort?

As I recall, it was necessary to disable the cache in the idle task so
that the idle task's clearing of pages didn't trash the cache for
other tasks.  This introduces its own set of complexities, for example
you have to make sure the cache is reenabled on all exception entries
and also before you call schedule in the idle task.  You also have to
make sure that you don't get any inconsistencies in the cache, which
means you would have to flush the cache for the page before starting
to clear it with the cache disabled.

It would be cleaner to have the page mapped with a non-cacheable
mapping while the idle task is clearing it but you still have to be
careful about cache inconsistencies, particularly if the page is
mapped twice and one mapping is cacheable and the other isn't.

I'm not sure that the current code still addresses all those issues
correctly and completely.  Unused things tend to be subject to
bitrot. :-)

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

ld bug?

[Takashi Oe]

Hi,

Well, I've just had a kernel hang at "Freeing unused kernel memory:..."
with linux-2.4.0-test8 + numerous patches, and I've traced the hang to
what apears (to me) to be a ld bug.

The kernel hangs at the call to spin_unlock_irq() in schedule() of
kernel/sched.c.  For me (UP kernel), spin_unlock_irq() is defined to be

struct int_control_struct
{
	void (*int_cli)(void);
	void (*int_sti)(void);
	void (*int_restore_flags)(unsigned long);
	void (*int_save_flags)(unsigned long *);
	void (*int_set_lost)(unsigned long);
};
extern struct int_control_struct int_control;

extern void __no_use_sti(void);

#define __sti()			int_control.int_sti()
#define local_irq_enable()	__sti()
#define spin_unlock(lock)	do { } while (0)
#define spin_unlock_irq(lock)	\
	do { spin_unlock(lock);  local_irq_enable();       } while (0)


>From objdump output of kernel/sched.o:

     458:       3d 20 00 00     lis     r9,0
                        45a: R_PPC_ADDR16_HA    int_control+0x4
     45c:       80 09 00 04     lwz     r0,4(r9)
                        45e: R_PPC_ADDR16_LO    int_control+0x4
     460:       7c 08 03 a6     mtlr    r0
     464:       4e 80 00 21     blrl

So, if I'm reading this correctly, the compiler is generating correct
assembly.  Now, objdump output of vmlinux (kernel) for the same segment
says:

c02164c4:       3d 20 c0 3a     lis     r9,-16326
c02164c8:       80 09 c3 e4     lwz     r0,-15388(r9)
c02164cc:       7c 08 03 a6     mtlr    r0
c02164d0:       4e 80 00 21     blrl

However, from "nm vmlinux | grep int_control", "int_control" is at

c039c3e0 D int_control

as opposed to c03ac3e0 used in vmlinux.  So, it appears that ld or
something is acting up.  I've tried various version of binutils from
2.9.1.0.990418 to 2.10.0.18, but all have produced the same output.
Except for 2.9.1.0.990414, all 2.10.x versions that I tried are from
ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/.

gcc is 2.95.3-2c (also from fsirl directory).

If I change some totally (and seemingly) unrelated files a bit, vmlinux
produced may be correct.  I tried to look at if any section's size
matters, but I don't see any pattern unfortunately.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Takashi Oe]

On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:

> On the m68k, we have some code to guestimate the CPU clock based on the
> BogoMIPS (see get_cpuinfo() in arch/m68k/kernel/setup.c). Since we didn't care
> about the overhead incurred by interrupt processing, it's not that accurate
> though (I get 24.8 MHz on my 25 MHz 68040).

That thought had occured to me.  Only problem is that the relationship
between bogomips and cpu clock speed depends on, well, CPU.  For 601, it's
one to one, and, for 604, two to one, and so on.  I don't know the ratios
for 603, G3, or G4.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Kaoru Fukui]

From: Takashi Oe <toe@unlserve.unl.edu>
To: linuxppc-dev@lists.linuxppc.org
Subject: ld bug?
Date: Thu, 14 Sep 2000 21:28:46 -0500 (CDT)

>
> Hi,

> as opposed to c03ac3e0 used in vmlinux.  So, it appears that ld or
> something is acting up.  I've tried various version of binutils from
> 2.9.1.0.990418 to 2.10.0.18, but all have produced the same output.
> Except for 2.9.1.0.990414, all 2.10.x versions that I tried are from
> ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/.
>
> gcc is 2.95.3-2c (also from fsirl directory).
>
> If I change some totally (and seemingly) unrelated files a bit, vmlinux
> produced may be correct.  I tried to look at if any section's size
> matters, but I don't see any pattern unfortunately.
>

Lastest binutls is  2.10.0.24.

It's there.

ftp://ftp.valinux.com/pub/support/hjl/binutils/

Kaoru

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Paul Mackerras]

Takashi Oe writes:

> Well, I've just had a kernel hang at "Freeing unused kernel memory:..."
> with linux-2.4.0-test8 + numerous patches, and I've traced the hang to
> what apears (to me) to be a ld bug.

Don't think so, see below...

> The kernel hangs at the call to spin_unlock_irq() in schedule() of
> kernel/sched.c.  For me (UP kernel), spin_unlock_irq() is defined to be

That sounds to me like an unhandled interrupt, endlessly repeated.

> So, if I'm reading this correctly, the compiler is generating correct
> assembly.  Now, objdump output of vmlinux (kernel) for the same segment
> says:
>
> c02164c4:       3d 20 c0 3a     lis     r9,-16326
> c02164c8:       80 09 c3 e4     lwz     r0,-15388(r9)
> c02164cc:       7c 08 03 a6     mtlr    r0
> c02164d0:       4e 80 00 21     blrl
>
> However, from "nm vmlinux | grep int_control", "int_control" is at
>
> c039c3e0 D int_control

No, it's right, the thing is that the -15388 in the lwz instruction is
sign-extended.  So the address it uses is 0xc03a0000 - 15388 (or put
another way, 0xc03a0000 + 0xffffc3e4) which is in 0xc039c3e0.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: ld bug?

[Takashi Oe]

Hi,

On Fri, 15 Sep 2000, Paul Mackerras wrote:

> Takashi Oe writes:
>
> > Well, I've just had a kernel hang at "Freeing unused kernel memory:..."
> > with linux-2.4.0-test8 + numerous patches, and I've traced the hang to
> > what apears (to me) to be a ld bug.
>
> Don't think so, see below...
>
> > The kernel hangs at the call to spin_unlock_irq() in schedule() of
> > kernel/sched.c.  For me (UP kernel), spin_unlock_irq() is defined to be
>
> That sounds to me like an unhandled interrupt, endlessly repeated.

To be more precise on the "hang", the cursor is blinking normally as if
something will happen shortly (but won't), and I can invoke xmon via NMI
just fine.  When I invoked xmon, LR is at right after spin_unlock_irq()
and PC is at "blr" of __no_use_sti(), so obviously my previous
interpretation was way wrong.  Sorry.

[...]
> > However, from "nm vmlinux | grep int_control", "int_control" is at
> >
> > c039c3e0 D int_control
>
> No, it's right, the thing is that the -15388 in the lwz instruction is
> sign-extended.  So the address it uses is 0xc03a0000 - 15388 (or put
> another way, 0xc03a0000 + 0xffffc3e4) which is in 0xc039c3e0.

Thanks!  That makes a lot of sense.  I'm really glad I don't have to
compile binutils myself.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Timothy A. Seufert]

At 9:35 PM -0500 9/14/00, Takashi Oe wrote:
>On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:
>
>>  On the m68k, we have some code to guestimate the CPU clock based on the
>>  BogoMIPS (see get_cpuinfo() in arch/m68k/kernel/setup.c). Since we
>>didn't care
>>  about the overhead incurred by interrupt processing, it's not that accurate
>>  though (I get 24.8 MHz on my 25 MHz 68040).
>
>That thought had occured to me.  Only problem is that the relationship
>between bogomips and cpu clock speed depends on, well, CPU.  For 601, it's
>one to one, and, for 604, two to one, and so on.  I don't know the ratios
>for 603, G3, or G4.

It gets more fun than that.  I've found that the G3's ratio varies
depending on how many of its features are turned on.  It's usually
2:1, but if the BTIC and BHT (Branch Target Instruction Cache, Branch
History Table) are turned off, it drops way down (1:1 I think, but I
may be misremembering).

Why would they be off, you ask?  Because Apple's OF doesn't always
turn them on.  I found out when I upgraded a B&W G3 from its original
CPU to a 450 MHz G3; all of a sudden my BogoMIPS were actually lower
than they were before the upgrade.  The real world performance
difference I've measured from BTIC & BHT being on/off is more like
5-10%, but it was rather startling to see BogoMIPS go down when the
clock speed went up.

The point may be moot, because I think recent kernel versions always
turn on BTIC and BHT during initialization.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Geert Uytterhoeven]

On Thu, 14 Sep 2000, Takashi Oe wrote:
> On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:
> > On the m68k, we have some code to guestimate the CPU clock based on the
> > BogoMIPS (see get_cpuinfo() in arch/m68k/kernel/setup.c). Since we didn't care
> > about the overhead incurred by interrupt processing, it's not that accurate
> > though (I get 24.8 MHz on my 25 MHz 68040).
>
> That thought had occured to me.  Only problem is that the relationship
> between bogomips and cpu clock speed depends on, well, CPU.  For 601, it's
> one to one, and, for 604, two to one, and so on.  I don't know the ratios
> for 603, G3, or G4.

It's the same on m68k. Originally I had the ratios for 68040 only (and for
68000, which didn't matter at that time), but very soon I found them out for
other CPUs. All you need is a few testers :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Holger Bettag]

"Timothy A. Seufert" <tas@mindspring.com> writes:

>
>
> At 9:35 PM -0500 9/14/00, Takashi Oe wrote:
> >On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:
> >
> >>  On the m68k, we have some code to guestimate the CPU clock based on the
> >>  BogoMIPS (see get_cpuinfo() in arch/m68k/kernel/setup.c). Since we
> >>  didn't care about the overhead incurred by interrupt processing, it's
> >>  not that accurate though (I get 24.8 MHz on my 25 MHz 68040).
> >
> >That thought had occured to me.  Only problem is that the relationship
> >between bogomips and cpu clock speed depends on, well, CPU.  For 601, it's
> >one to one, and, for 604, two to one, and so on.  I don't know the ratios
> >for 603, G3, or G4.
>
> It gets more fun than that.  I've found that the G3's ratio varies
> depending on how many of its features are turned on.  It's usually
> 2:1, but if the BTIC and BHT (Branch Target Instruction Cache, Branch
> History Table) are turned off, it drops way down (1:1 I think, but I
> may be misremembering).
>
Would a rewrite of the bogomips loop be an option?

In that case one could chose a sequence of dependant instructions in
the loop body, preventing possible superscalar execution. (One could
specifically use instructions that are commonly 'execution
serializing', like 'adde', to again enforce execution of only a single
instruction per clock.)

If the loop body was long enough, effects of varying branching
efficiency could also be masked. That way, bogomips should correlate
very well with actual MHz.

  Holger

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Michael Schmitz]

> Would a rewrite of the bogomips loop be an option?

Not really. The bogomips loop is meant to calibrate short delay loops used
elsewhere in the kernel.

You can always add another calibration loop for the MHz if you absolutely
need to.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Takashi Oe]

On Fri, 15 Sep 2000, Michael Schmitz wrote:
>
> > Would a rewrite of the bogomips loop be an option?
>
> Not really. The bogomips loop is meant to calibrate short delay loops used
> elsewhere in the kernel.
>
> You can always add another calibration loop for the MHz if you absolutely
> need to.

Using the bogomips as it is is cheap, so I think I'll code up with that
and add "(maybe wrong by 1 MHz or more)" or something for /proc/cpuinfo's
clock field.  Or remove that field all together where the information is
not readily available.


Takashi Oe


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Adrian Cox]

Paul Mackerras wrote:

> It would be cleaner to have the page mapped with a non-cacheable
> mapping while the idle task is clearing it but you still have to be
> careful about cache inconsistencies, particularly if the page is
> mapped twice and one mapping is cacheable and the other isn't.

It might be interesting to try using a DMA engine on MPC 106/107 systems
to clear pages in the background. I've seen some simulations which
suggest that this could be a big win, but I'd have to spend a while
digging through the IEEE archives to find them again.

- Adrian Cox, AG Electronics

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Benjamin Herrenschmidt]

>> It would be cleaner to have the page mapped with a non-cacheable
>> mapping while the idle task is clearing it but you still have to be
>> careful about cache inconsistencies, particularly if the page is
>> mapped twice and one mapping is cacheable and the other isn't.
>
>It might be interesting to try using a DMA engine on MPC 106/107 systems
>to clear pages in the background. I've seen some simulations which
>suggest that this could be a big win, but I'd have to spend a while
>digging through the IEEE archives to find them again.

I didn't find any mention of a DMA engine in the MPC106... Or did I miss
something ?

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Adrian Cox]

Benjamin Herrenschmidt wrote:

> I didn't find any mention of a DMA engine in the MPC106... Or did I miss
> something ?

You're probably right - I never worked with the 106, but went straight
to the 107.

- Adrian Cox, AG Electronics

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Matt Porter]

On Mon, Sep 18, 2000 at 03:58:20PM +0100, Adrian Cox wrote:
>
> Benjamin Herrenschmidt wrote:
>
> > I didn't find any mention of a DMA engine in the MPC106... Or did I miss
> > something ?
>
> You're probably right - I never worked with the 106, but went straight
> to the 107.

Yes, the 107 is the first Mot. Semi bridge to incorporate a DMA engine.
The IBM CPC710 and 405GP both have DMA engines that could be used this
way as well.

--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Gabriel Paubert]

On Wed, 13 Sep 2000, Paul Mackerras wrote:

>
> Michel Lanners writes:
>
> > clock           : 195MHz
> >                   ^^^^^^
> > (by the way, this is wrong. Anybody with a fix?)
>
> I'm pretty sure that this is the number that OF is telling us, so if
> it's wrong, blame OF.  You don't have a G3 upgrade card in an older
> machine perhaps?
>
> Since the only use of this number is for oohs and aahs, there's not a
> lot of motivation to try and work out if OF is wrong and work out the
> correct number.

It's not only OF, on my MVME machines with PPCBUG, I get 190 Mhz instead
of 200. This value could be computed from the decrementer frequency and
the clock multiplier (can be obtained from HID1 on some processors and
has to be guessed on others). The 601 will require a different method, but
can still be estimated quite precisely I believe.

Now, is is truly worth the effort ?

	Gabriel (slowly reducing my email backlog after 2 weeks away)...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Gabriel Paubert]

On Thu, 14 Sep 2000, Paul Mackerras wrote:

>
> Michel Lanners writes:
>
> > > - if not, would it be a good idea to enable it by default?
> >
> > What do you think, Paul, Cort?
>
> As I recall, it was necessary to disable the cache in the idle task so
> that the idle task's clearing of pages didn't trash the cache for
> other tasks.

why ? When you are sleeping, the next task to run may or may not be the
same.

If it is the same, you loose, but any task sleeping should not expect
the caches to be hot when it restarts....

It it is not the same and you take care of cleaning the cache (with dcbst,
not dcbf to opimize the case where you need a new allocation just after
the switch to an active task), then you will end up with less dirty cache
line pushes when the new task is started, effectively speeding up the task
switch.

On SMP bus utlilization may be an issue, but dcbz+dcbst is not that
expensive after all (2 address cycles and one data burst).

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: zeroing pages in the idle task?

[Paul Mackerras]

Gabriel Paubert writes:

> On Thu, 14 Sep 2000, Paul Mackerras wrote:
> > As I recall, it was necessary to disable the cache in the idle task so
> > that the idle task's clearing of pages didn't trash the cache for
> > other tasks.
>
> why ? When you are sleeping, the next task to run may or may not be the
> same.
>
> If it is the same, you loose, but any task sleeping should not expect
> the caches to be hot when it restarts....

Cort did the measurements, I don't recall the actual numbers myself.
I think that what was happening was that the idle task would run
e.g. during a disk read and the net effect with things like a kernel
compile was that it ran slower overall when the idle task was clearing
pages with the cache enabled.  Cort's solution was to disable the
cache entirely while the idle task was running.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/