From: Michel Lanners <hidden> Date: 2000-09-12 20:18:48
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/
From: Paul Mackerras <hidden> Date: 2000-09-13 03:46:17
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/
From: Michel Lanners <hidden> Date: 2000-09-13 06:08:55
Hi Paul,
On 13 Sep, this message from Paul Mackerras echoed through cyberspace:
Michel Lanners writes:
quoted
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/
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-13 10:45:16
quoted
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/
From: David A. Gatwood <hidden> Date: 2000-09-13 16:23:48
On Wed, 13 Sep 2000, Takashi Oe wrote:
quoted
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/
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/
From: Michel Lanners <hidden> Date: 2000-09-13 19:51:25
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/
From: Paul Mackerras <hidden> Date: 2000-09-14 04:44:42
Michel Lanners writes:
quoted
- 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/
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/
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/
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/
From: Paul Mackerras <hidden> Date: 2000-09-15 03:16:57
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/
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...
quoted
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.
[...]
quoted
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/
From: Timothy A. Seufert <hidden> Date: 2000-09-15 04:50:43
At 9:35 PM -0500 9/14/00, Takashi Oe wrote:
On Wed, 13 Sep 2000, Geert Uytterhoeven wrote:
quoted
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/
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/
From: Adrian Cox <hidden> Date: 2000-09-18 14:26:52
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/
From: Benjamin Herrenschmidt <hidden> Date: 2000-09-18 14:41:49
quoted
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/
From: Adrian Cox <hidden> Date: 2000-09-18 14:58:20
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/
From: Gabriel Paubert <hidden> Date: 2000-09-26 10:18:51
On Wed, 13 Sep 2000, Paul Mackerras wrote:
Michel Lanners writes:
quoted
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/
From: Gabriel Paubert <hidden> Date: 2000-09-26 10:38:59
On Thu, 14 Sep 2000, Paul Mackerras wrote:
Michel Lanners writes:
quoted
quoted
- 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/
From: Paul Mackerras <hidden> Date: 2000-09-27 05:24:22
Gabriel Paubert writes:
On Thu, 14 Sep 2000, Paul Mackerras wrote:
quoted
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/