Re: 2.5.64-mm6

Re: 2.5.64-mm6

[Felipe Alfaro Solana]

----- Original Message ----- 
From: Andrew Morton <akpm@digeo.com> 
Date: 	Thu, 13 Mar 2003 03:26:15 -0800 
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org 
Subject: 2.5.64-mm6 
 
> . Added all of Russell King's PCMCIA changes.  If anyone tests this on 
>   cardbus/PCMCIA machines please let us know. 
 
Testing 2.5.64-mm6 on my NEC laptop, TI CardBus Bridge, 
3Com 3c575. No problems yet ;-) 
 
>   This means that large cache-cold executables start significantly faster. 
>   Launching X11+KDE+mozilla goes from 23 seconds to 16.  Starting OpenOffice 
>   seems to be 2x to 3x faster, and starting Konqueror maybe 3x faster too.  
>   Interesting. 
 
I feel the system a little bit faster and more responsive. I've also set 
max_timeslice to 50 to experiment a little more with interactive loads. 
 
Thanks! 
 
   Felipe 
 
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Alexander Hoogerhuis]

Andrew Morton <akpm@digeo.com> writes:

> Alexander Hoogerhuis <alexh@ihatent.com> wrote:
> >
> > I've used tried the -mm-kernels since they've actually made
> > 2.5-kernels usable on my laptop lately (Compaq Evo800c), but
> > 2.5.64-mm2 and onwards doesnt work with X anymore. I run 4.3.0-r1 from
> > the Gentoo unstable "branch".
> > 
> > with -mm1 I X coming up just nicely, and now the screen just goes
> > black after trying to start X, and it seems related to DRM.
> 
> I have a radeon card here.  Just tried it.  The X server starts up OK but as
> soon as I run tuxracer, some ioctl down in the radeon driver keeps on timing
> out waiting for the FIFO, spins for ten milliseconds in-kernel and the X
> server immediately calls the ioctl again.  The whole thing is bust.  I went
> all the way back to 2.5.39, where it is still bust.  2.4.21-pre5 is OK
> though.
> 
> So it looks like my breakage is different from yours.
> 
> Could you please try just 2.5.64 plus
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/broken-out/linus.patch
> 
> That will tell us if it is a -mm bug or a -linus bug.
> 

Vanilla 2.5.64 is b0rken, too. Tried it, and went back and tries -mm6
with and without ACPI as well, no difference. So instead of trudging
through that liste of change sets, I'll back out one and one patch
from -mm1 back to plain .64 to see where the thing goes belly
up. Seems reasonable?

mvh,
A
-- 
Alexander Hoogerhuis                               | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE                          | +47 908 21 485
"You have zero privacy anyway. Get over it."  --Scott McNealy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Andrew Morton]

Eli Carter <eli.carter@inet.com> wrote:
>
> If I can feed you changes to kgdb, would you be interested in taking 
> them?

Sure.

> What was the last patch you shipped with George's version?

Long time ago.  I'll send you the latest.

> Which do you think would be the right place to start?

George's.  It enters the debugger way earlier in boot and appears to have
stronger SMP support.  Has more features, etc.

> "We"... I like that word.  ;)  If you can act as 'upstream' for my 
> changes and answer quick questions, I'll feed you patches.

Sure.  The patches are against base 2.5.x, so your work will be separated
from -mm goings-on.

> I'm thinking I'll try to wind up with 2 or 3 patches, kgdb.patch, 
> kgdb-arm.patch, and kgdb-ia32.patch.  Maybe.

That sounds appropriate.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Eli Carter]

Andrew Morton wrote:
> Eli Carter <eli.carter@inet.com> wrote:
> 
>>Andrew Morton wrote:
>>
>>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
>>
>>[snip]
>>
>>>kgdb.patch
>>
>>I'm interested in this patch in your tree.
> 
> 
> You're brave.

Heh.  Insane might be more like it. ;)

> The kgdb patch is pretty nasty-looking code.  I've managed to keep it working
> for every kernel since 2.4.0-test10 while avoiding actually looking at it. 
> (I turn the monitor off when the patch needs fixing).  Fed it through Lindent
> once.
> 
> George Anzinger is maintaining another strain of the stub, and that mostly
> works OK and has improved features.  But the diff is larger and I once had a
> couple of problems with it and need to spend more time testing it.  It's up
> to date though.

If I can feed you changes to kgdb, would you be interested in taking 
them?  What was the last patch you shipped with George's version?  Which 
do you think would be the right place to start?


>>Would breaking the arch-independent parts out to linux/kernel/gdbstub.c 
>>be a reasonable change or is that a dumb question? ;)
> 
> 
> That would be a fantastic thing to do.  Note that there are already about ten
> kgdb stubs in the shipped kernel at present.  If you can identify exactly
> which functions need to be provided by the architecture, pull that out into
> struct kgdb_operations, etc then it would make maintenance and addition of
> new support much easier.

I guess I'll go hunting. :)

> We might even end up with something we could submit for inclusion without
> first having to set up an itwasntmenobodysawmedoit@yahoo.com account.

"We"... I like that word.  ;)  If you can act as 'upstream' for my 
changes and answer quick questions, I'll feed you patches.  Some testing 
of x86 would be wonderful too.  (And while I'm at it, can I send you my 
Christmas wishlist? ;) )  I have to warn you, I don't know how far I'll 
get.  But I'll give it a shot.  My current concern is getting it working 
under ARM, and there is a kgdb patch for 2.4 ARM I can draw from.

I'm thinking I'll try to wind up with 2 or 3 patches, kgdb.patch, 
kgdb-arm.patch, and kgdb-ia32.patch.  Maybe.

Are you feeling "brave"? 8)

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Andrew Morton]

Eli Carter <eli.carter@inet.com> wrote:
>
> Andrew Morton wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
> [snip]
> > kgdb.patch
> 
> I'm interested in this patch in your tree.

You're brave.

The kgdb patch is pretty nasty-looking code.  I've managed to keep it working
for every kernel since 2.4.0-test10 while avoiding actually looking at it. 
(I turn the monitor off when the patch needs fixing).  Fed it through Lindent
once.

George Anzinger is maintaining another strain of the stub, and that mostly
works OK and has improved features.  But the diff is larger and I once had a
couple of problems with it and need to spend more time testing it.  It's up
to date though.

> (Just to warn you of my 
> biases, I'm currently working with the XScale/ARM arch.)  I've noticed 
> some things about it in an initial look, namely:
> 
> There appears to be some code duplication between hex() and stubhex() in 
> arch/i386/kernel/gdbstub.c.

No surprise there.

> Also, the bulk of gdbstub.c appears to be generic code.  There are a 
> number of functions that have x86 asm in them, but it looks to me on 
> initial viewing, that most of the logic is applicable to other arches. 
> Am I understanding that correctly?
> Right now it looks like an arch would need to provide a way to:
> - reboot the processor
> - implement 'continue at address' and 'step one instruction from address'
> - handle_exeption()
> - printexception()
> - correct_hw_break()
> - regs_to_gdb_regs() and gdb_regs_to_regs()
>      Hmm, there's probably some more to that part...
> The above is just for the gdbstub.c.  I'm still reading the patch. :)
> 
> Would breaking the arch-independent parts out to linux/kernel/gdbstub.c 
> be a reasonable change or is that a dumb question? ;)

That would be a fantastic thing to do.  Note that there are already about ten
kgdb stubs in the shipped kernel at present.  If you can identify exactly
which functions need to be provided by the architecture, pull that out into
struct kgdb_operations, etc then it would make maintenance and addition of
new support much easier.

We might even end up with something we could submit for inclusion without
first having to set up an itwasntmenobodysawmedoit@yahoo.com account.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Eli Carter]

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
[snip]
> kgdb.patch

I'm interested in this patch in your tree.  (Just to warn you of my 
biases, I'm currently working with the XScale/ARM arch.)  I've noticed 
some things about it in an initial look, namely:

There appears to be some code duplication between hex() and stubhex() in 
arch/i386/kernel/gdbstub.c.

Also, the bulk of gdbstub.c appears to be generic code.  There are a 
number of functions that have x86 asm in them, but it looks to me on 
initial viewing, that most of the logic is applicable to other arches. 
Am I understanding that correctly?
Right now it looks like an arch would need to provide a way to:
- reboot the processor
- implement 'continue at address' and 'step one instruction from address'
- handle_exeption()
- printexception()
- correct_hw_break()
- regs_to_gdb_regs() and gdb_regs_to_regs()
     Hmm, there's probably some more to that part...
The above is just for the gdbstub.c.  I'm still reading the patch. :)

Would breaking the arch-independent parts out to linux/kernel/gdbstub.c 
be a reasonable change or is that a dumb question? ;)

Thanks,

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Andrew Morton]

Helge Hafting <helgehaf@aitel.hist.no> wrote:
>
> Andrew Morton wrote:
> >   This might cause weird thing to happen, especially on small-memory machines.
> 
> Weird things happened.
> mm1 (and mm2 on smp) have been running very fine for me. So I decided to 
> try mm6 on UP.  The machine have 512M, and uses soft raid-1 on /  The
> rest is plain ide disk partitions, all using ext2.
> 
> It booted fine.
> I fired up openoffice, a 2x-3x speedup ought to be noticeable.
> It didn't start, but got stuck with the annoying on-top-of-everything 
> splash screen showing.  ps aux showed lpd in D state - perhaps
> oo queries lpd.  I also tried mozilla, and it got stuck in D state too.
> Openoffice was only in sleep so I killed it.  Mozilla was unkillable
> as expected from the D state.

The elevator bug.  I'll make deadline the deefault until we get this sorted.
Booting with "elevator=deadline" should be OK.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Helge Hafting]

Andrew Morton wrote:
>   This might cause weird thing to happen, especially on small-memory machines.

Weird things happened.
mm1 (and mm2 on smp) have been running very fine for me. So I decided to 
try mm6 on UP.  The machine have 512M, and uses soft raid-1 on /  The
rest is plain ide disk partitions, all using ext2.

It booted fine.
I fired up openoffice, a 2x-3x speedup ought to be noticeable.
It didn't start, but got stuck with the annoying on-top-of-everything 
splash screen showing.  ps aux showed lpd in D state - perhaps
oo queries lpd.  I also tried mozilla, and it got stuck in D state too.
Openoffice was only in sleep so I killed it.  Mozilla was unkillable
as expected from the D state.

I've heard that this is supposed to be an anticipatory scheduler bug, 
and started looking for information on how to use deadline. But 
everything suddenly came loose and things works normally now.

Openoffice and mozilla starts just fine now.  I guess AS have some
boot trouble, or could it be a jiffy wraparound issue? (Assuming
2.5.64-mm6 starts the counter near a wrap)

Please tell if there's anything I can do to test further.

Helge Hafting




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Andrew Morton]

Alexander Hoogerhuis <alexh@ihatent.com> wrote:
>
> I've used tried the -mm-kernels since they've actually made
> 2.5-kernels usable on my laptop lately (Compaq Evo800c), but
> 2.5.64-mm2 and onwards doesnt work with X anymore. I run 4.3.0-r1 from
> the Gentoo unstable "branch".
> 
> with -mm1 I X coming up just nicely, and now the screen just goes
> black after trying to start X, and it seems related to DRM.

I have a radeon card here.  Just tried it.  The X server starts up OK but as
soon as I run tuxracer, some ioctl down in the radeon driver keeps on timing
out waiting for the FIFO, spins for ten milliseconds in-kernel and the X
server immediately calls the ioctl again.  The whole thing is bust.  I went
all the way back to 2.5.39, where it is still bust.  2.4.21-pre5 is OK
though.

So it looks like my breakage is different from yours.

Could you please try just 2.5.64 plus
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/broken-out/linus.patch

That will tell us if it is a -mm bug or a -linus bug.

It it is the latter, and if you're feeling really keen then could you search through the patches at 
http://www.zip.com.au/~akpm/linux/patches/2.5/badari/
and work out exactly which one introduced the problem?

Each of those patches is against 2.5.64.   The chronological order is:

cset-1.1085-to-1.1085.txt.gz
cset-1.1085-to-1.1086.txt.gz
cset-1.1085-to-1.1089.txt.gz
cset-1.1085-to-1.1090.txt.gz
cset-1.1085-to-1.1091.txt.gz
cset-1.1085-to-1.1094.txt.gz
cset-1.1068.1.17-to-1.1075.txt.gz
cset-1.1068.1.17-to-1.1077.txt.gz
cset-1.1068.1.17-to-1.1106.txt.gz
cset-1.1068.1.17-to-1.1107.txt.gz
cset-1.1068.1.17-to-1.1110.txt.gz
cset-1.1068.1.17-to-1.1122.txt.gz
cset-1.1068.1.17-to-1.1123.txt.gz
cset-1.1068.1.17-to-1.1124.txt.gz
cset-1.1068.1.17-to-1.1125.txt.gz
cset-1.1068.1.17-to-1.1127.txt.gz
cset-1.1068.1.17-to-1.1131.txt.gz
cset-1.1068.1.17-to-1.1137.txt.gz
cset-1.1068.1.17-to-1.1160.txt.gz
cset-1.1068.1.17-to-1.1166.txt.gz
cset-1.1068.1.17-to-1.1168.txt.gz
cset-1.1068.1.17-to-1.1171.txt.gz
cset-1.1068.1.17-to-1.1173.txt.gz
cset-1.1068.1.17-to-1.1174.txt.gz
cset-1.1068.1.17-to-1.1175.txt.gz
cset-1.1068.1.17-to-1.1177.txt.gz
cset-1.1068.1.17-to-1.1101.txt.gz
cset-1.1068.1.17-to-1.1113.txt.gz
cset-1.1068.1.17-to-1.1119.txt.gz
cset-1.1068.1.17-to-1.1147.txt.gz
cset-1.1068.1.17-to-1.1154.txt.gz
cset-1.1068.1.17-to-1.1157.txt.gz

Thanks.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Alexander Hoogerhuis]

I've used tried the -mm-kernels since they've actually made
2.5-kernels usable on my laptop lately (Compaq Evo800c), but
2.5.64-mm2 and onwards doesnt work with X anymore. I run 4.3.0-r1 from
the Gentoo unstable "branch".

with -mm1 I X coming up just nicely, and now the screen just goes
black after trying to start X, and it seems related to DRM. With
-mm[56] the last bit I see in my X startup is this:

(==) RADEON(0): Write-combining range (0x88000000,0x4000000)
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
[HANG]

With -mm1 and 2.4.21preX it shows this:
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: open result is -1, (No such device)
drmOpenDevice: Open failed
drmOpenDevice: minor is 0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 6, (OK)
drmGetBusid returned ''
(II) RADEON(0): [drm] loaded kernel module for "radeon" driver
(II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xf098d000
(II) RADEON(0): [drm] mapped SAREA 0xf098d000 to 0x40013000
.
.
.

Although it hangs under -mm[56] the machine will still respond to
CRTL-ALT-DEL and reboot nicely. The only modification to the kernel
I've done it backing out smalldevfs (Gentoo likes to have the full
thing). I've also tried having the DRM-stuff as modules and as
compiled in, no difference

The graphics adapter is a Radeon with 64Mb RAM:

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA])
        Subsystem: Compaq Computer Corporation: Unknown device 004a
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
        Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 66 (2000ns min), cache line size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at 3000 [size=256]
        Region 2: Memory at 80380000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: [58] AGP version 2.0
                Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4
                Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Other than that 2.5.64-mm6 is very usable, but only in text mode.

mvh,
A

Andrew Morton <akpm@digeo.com> writes:

> [SNIP]
-- 
Alexander Hoogerhuis                               | alexh@ihatent.com
CCNP - CCDP - MCNE - CCSE                          | +47 908 21 485
"You have zero privacy anyway. Get over it."  --Scott McNealy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Robert Love]

On Thu, 2003-03-13 at 22:46, Shawn wrote:

> This reminds me of something I've not looked into for some time.
> 
> Being an active user of the 2.5 series including -mm, should I have
> updated glibc, or is there nothing new enough yet to warrant that?

In 2.3 and beyond (current is 2.3.2 I think), there are a few 2.5
changes.  Nothing required, though.

The biggest is NPTL, which takes advantage of all the threading stuff.

There is also sysenter support.

And support for new 2.5 system calls - most, but not all, of them are
there.  I know the affinity calls are.  And the new posix_fadvise().

> Maybe I should just ask the glibc people. Wasn't sure what the proper
> forum was.

libc-alpha is the public glibc list.  It is hosted at
sources.redhat.com.

	Robert Love

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Andrew Morton]

Shawn <core@enodev.com> wrote:
>
> Being an active user of the 2.5 series including -mm, should I have
> updated glibc, or is there nothing new enough yet to warrant that?

I think so, yes.  There is the threading support and also the new
sysenter system-call entry code.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Shawn]

On Thu, 2003-03-13 at 21:28, Andrew Morton wrote:
> Steven Cole <elenstev@mesatop.com> wrote:
> >
> > On Thu, 2003-03-13 at 12:34, Andrew Morton wrote:
> > > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > > >
> > > > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > > > >   This means that when an executable is first mapped in, the kernel will
> > > > >   slurp the whole thing off disk in one hit.  Some IO changes were made to
> > > > >   speed this up.
> > > > 
> > > > Does this just pull in text and data, or will it pull any debug sections
> > > > too?  That could fill memory with a lot of useless junk.
> > > > 
> > > 
> > > Just text, I expect.  Unless glibc is mapping debug info with PROT_EXEC ;)
> > > 
> > > It's just a fun hack.  Should be done in glibc.
> > 
> > Well, fun hack or glibc to-do list candidate, I hope it doesn't get
> > forgotten.
> 
> I have to pull the odd party trick to get people to test -mm kernels.

This reminds me of something I've not looked into for some time.

Being an active user of the 2.5 series including -mm, should I have
updated glibc, or is there nothing new enough yet to warrant that?

Maybe I should just ask the glibc people. Wasn't sure what the proper
forum was.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Andrew Morton]

Steven Cole <elenstev@mesatop.com> wrote:
>
> On Thu, 2003-03-13 at 12:34, Andrew Morton wrote:
> > Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> > >
> > > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > > >   This means that when an executable is first mapped in, the kernel will
> > > >   slurp the whole thing off disk in one hit.  Some IO changes were made to
> > > >   speed this up.
> > > 
> > > Does this just pull in text and data, or will it pull any debug sections
> > > too?  That could fill memory with a lot of useless junk.
> > > 
> > 
> > Just text, I expect.  Unless glibc is mapping debug info with PROT_EXEC ;)
> > 
> > It's just a fun hack.  Should be done in glibc.
> 
> Well, fun hack or glibc to-do list candidate, I hope it doesn't get
> forgotten.

I have to pull the odd party trick to get people to test -mm kernels.

> I am happy to confirm that it did speed up the initial
> launch time of Open Office from 20 seconds (2.5-bk) to 11 seconds (-mm6)
> and Mozilla from 10 seconds (2.5-bk) to 6 seconds (-mm6).

OK, thanks for confirming that.  Both these apps are *very* compute-intensive
at startup.  Try starting them when everything is in cache...  The
proportional benefits for saner apps wil be larger.

As for glibc, yup, the two-liner which I mentioned is a good start.  Finer
tuning would involve looking at the data segments, dlopen(), etc.  A fun
project.

One subtlety: the linker (ld) lays files out very poorly.  So the prefaulting
trick will not help much when run against an executable which was written by
ld.  But if you've copied it into /bin (make install) then it will work well.
That's something to watch out for.


Doing it in madvise may work better actually.  madvise will pull the pages
into pagecache and leave them on the inactive list.  A subsequent minor fault
will activate the pages.  So the unneeded pages get thrown away quickly. 
Which is exactly what we want.

However -mm6 actually maps all the pages into the process's pagetables at
mmap() time.  That saves the cost of thousands of minor pagefaults, but it
means that the pages which we didn't really want will take longer to be
reclaimed.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Steven Cole]

On Thu, 2003-03-13 at 12:34, Andrew Morton wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >
> > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > >   This means that when an executable is first mapped in, the kernel will
> > >   slurp the whole thing off disk in one hit.  Some IO changes were made to
> > >   speed this up.
> > 
> > Does this just pull in text and data, or will it pull any debug sections
> > too?  That could fill memory with a lot of useless junk.
> > 
> 
> Just text, I expect.  Unless glibc is mapping debug info with PROT_EXEC ;)
> 
> It's just a fun hack.  Should be done in glibc.

Well, fun hack or glibc to-do list candidate, I hope it doesn't get
forgotten.  I am happy to confirm that it did speed up the initial
launch time of Open Office from 20 seconds (2.5-bk) to 11 seconds (-mm6)
and Mozilla from 10 seconds (2.5-bk) to 6 seconds (-mm6).

I did run 2.5.64-mm6 with mem=64M under stress for several hours and it
took a beating and kept on ticking, although quite slowly.

Steven


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Thomas Molina]

> Hmmm... I have experienced some hard locks similar to what 
> you describe: if I compile usb-uhci as a module, Phoebe3 
> (8.0.94) locks hard at the time of doing a "modprobe 
> usb-controller" (being usb-controller an alias for uhci-hcd) 
> during boot (rc.sysinit script). To fix this, I have had  to compile 
> usb-uhci in to the kernel and then fix rc.sysinit. I haven't tried 
> using usb-uhci as a module since then. 
>  
> What's curious is that doing a "modprobe usb-controller" by 
> hand doesn't cause hard locks. So, there must be some kind 
> of timing or interaction that's causing rc.sysinit to invoke 
> "modprobe uchi-hcd" and freeze the machine. Any ideas? 

Not sure.  The configuration I used to build 2.5.64-mm6 was the same as 
every other 2.5 build I've used recently.  All of those included modular 
usb, so I don't believe it is that.  In my case 2.5.64-mm6 is the only 
version on which I see this.  My initial SWAG was some interaction between 
the new pcmcia core and usb, possibly at the pci layer.  I only ever try 
very few mm kernel versions, so I don't have a whole lot of data at the 
moment.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Felipe Alfaro Solana]

----- Original Message ----- 
From: Thomas Molina <tmolina@cox.net> 
Date: 	Thu, 13 Mar 2003 14:35:18 -0600 (CST) 
To: Andrew Morton <akpm@digeo.com> 
Subject: Re: 2.5.64-mm6 
 
> I downloaded the mm-6 patch and a pristine 2.5.64 tarball.  After applying  
> the patch I compiled with the standard configuration I've been using all  
> along.  No problems were noted during the compile cycle.  During bootup  
> the system locked up at the point where it did a modprobe uhci-hcd for the  
> USB controller.  Nothing of interest was noted in the log.  I rebooted  
> with nousb in the command line and got a good boot.  After working with  
> this kernel for awhile I don't see anything out of the ordainary except  
> that on a 2.5.64-bk kernel I get 330 Kbytes per second download speed  
> whereas with mm6 I get 280 Kbytes per second.  Several runs show this is  
> fairly consistent, with results within one or two percent. 
 
Hmmm... I have experienced some hard locks similar to what 
you describe: if I compile usb-uhci as a module, Phoebe3 
(8.0.94) locks hard at the time of doing a "modprobe 
usb-controller" (being usb-controller an alias for uhci-hcd) 
during boot (rc.sysinit script). To fix this, I have had  to compile 
usb-uhci in to the kernel and then fix rc.sysinit. I haven't tried 
using usb-uhci as a module since then. 
 
What's curious is that doing a "modprobe usb-controller" by 
hand doesn't cause hard locks. So, there must be some kind 
of timing or interaction that's causing rc.sysinit to invoke 
"modprobe uchi-hcd" and freeze the machine. Any ideas? 
 
   Felipe 
 
-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Thomas Molina]

On Thu, 13 Mar 2003, Andrew Morton wrote:

> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/
> 
> . Added all of Russell King's PCMCIA changes.  If anyone tests this on
>   cardbus/PCMCIA machines please let us know.

I decided to try it because of this.  My test machine was a Compaq 
Presario 12XL325, PIII-650, RedHat 8.0 with updates.  The cardbus bridge 
is listed as a TI PCI1410 controller.  I've been doing daily bk pulls and 
compiles on this machine for some time with no problems noted on the 
resulting kernel.  On the cardbus interface I have an SMC wireless NIC as 
modules.  

I downloaded the mm-6 patch and a pristine 2.5.64 tarball.  After applying 
the patch I compiled with the standard configuration I've been using all 
along.  No problems were noted during the compile cycle.  During bootup 
the system locked up at the point where it did a modprobe uhci-hcd for the 
USB controller.  Nothing of interest was noted in the log.  I rebooted 
with nousb in the command line and got a good boot.  After working with 
this kernel for awhile I don't see anything out of the ordainary except 
that on a 2.5.64-bk kernel I get 330 Kbytes per second download speed 
whereas with mm6 I get 280 Kbytes per second.  Several runs show this is 
fairly consistent, with results within one or two percent.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Roger Larsson]

On Thursday 13 March 2003 20:34, Andrew Morton wrote:
> Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> >
> > On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> > >   This means that when an executable is first mapped in, the kernel will
> > >   slurp the whole thing off disk in one hit.  Some IO changes were made 
> > >   to speed this up.
> > 
> > Does this just pull in text and data, or will it pull any debug sections
> > too?  That could fill memory with a lot of useless junk.
> > 
> 
> Just text, I expect.  Unless glibc is mapping debug info with PROT_EXEC ;)
> 
> It's just a fun hack.  Should be done in glibc.
> 

Are you sure? This is most useful during startup of system/programs, at that 
time you usually have LOTS of free memory. Later when there are less free
memory or your computer is on a memory budget it should not load it all.

Can the application decide? Should it?

/RogerL

-- 
Roger Larsson
Skelleftea
Sweden

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Andrew Morton]

Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>
> On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
> >   This means that when an executable is first mapped in, the kernel will
> >   slurp the whole thing off disk in one hit.  Some IO changes were made to
> >   speed this up.
> 
> Does this just pull in text and data, or will it pull any debug sections
> too?  That could fill memory with a lot of useless junk.
> 

Just text, I expect.  Unless glibc is mapping debug info with PROT_EXEC ;)

It's just a fun hack.  Should be done in glibc.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

Re: 2.5.64-mm6

[Jeremy Fitzhardinge]

On Thu, 2003-03-13 at 03:26, Andrew Morton wrote:
>   This means that when an executable is first mapped in, the kernel will
>   slurp the whole thing off disk in one hit.  Some IO changes were made to
>   speed this up.

Does this just pull in text and data, or will it pull any debug sections
too?  That could fill memory with a lot of useless junk.

	J

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>

2.5.64-mm6

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.64/2.5.64-mm6/

. Added all of Russell King's PCMCIA changes.  If anyone tests this on
  cardbus/PCMCIA machines please let us know.

. Starting to concentrate a bit more on the nonlinear mapping and objrmap
  patches.  These conflict to various degrees, but we seem to be getting that
  sorted now.

  To test the nonlinear mapping code more thoroughly I have arranged for all
  executable file-backed mmaps to be treated as nonlinear.

  This means that when an executable is first mapped in, the kernel will
  slurp the whole thing off disk in one hit.  Some IO changes were made to
  speed this up.

  This means that large cache-cold executables start significantly faster.
  Launching X11+KDE+mozilla goes from 23 seconds to 16.  Starting OpenOffice
  seems to be 2x to 3x faster, and starting Konqueror maybe 3x faster too. 
  Interesting.

  This might cause weird thing to happen, especially on small-memory machines.




Changes since 2.5.64-mm5:


+ppc64-compat-flock.patch
+ppc64-eeh-fix.patch
+ppc64-socketcall-fix.patch

 Various ppc64 build fixes

+remap-file-pages-2.5.63-a1.patch

 Reworked to apply before objrmap,

+hugh-remap-fix.patch

 The remap_file_pages part of hugh-nonlinear-fixes.patch

+fremap-limit-offsets.patch

 Constrain remap_file_pages() input to fit inside the file-offset-in-pte
 representation.  29 bits on ia32.

+fremap-all-mappings.patch

 Make all PROT_EXEC file-backed mmappings use MAP_POPULATE treatment.

+filemap_populate-speedup.patch

 Use large IOs for prefaulting.

+file-offset-in-pte-x86_64.patch

 Reworked for remap_file_pages offset limiting.

+file-offset-in-pte-ppc64.patch

 PPC64 support.  Untested...

+objrmap-nonlinear-fixes.patch

 The other part of hugh-nonlinear-fixes.patch

-hugh-nonlinear-fixes.patch

 Split up.

-brlock-1.patch
-brlock-2.patch
-brlock-3.patch
-brlock-4.patch
-brlock-5.patch
-brlock-6.patch
-brlock-7.patch
-brlock-8.patch

 Dropped.  Stephen has a new patch, but it doesn't compile.

+early-writeback-init.patch

 Intialsie writeback early for rootfs population.

+posix-timers-update.patch

 Permit long sleeps.

+e100-memleak-fix.patch

 Plug another leak.

+pcmcia-1-kill-get_foo_map.patch
+pcmcia-2-remove-bus_foo-abstractions.patch
+pcmcia-3-add-SOCKET_CARDBUS_CONFIG.patch
+pcmcia-4-add-locking.patch
+pcmcia-5-add-CONFIG_PCMCIA_PROBE.patch
+pcmcia-6-remove-old-cardbus-clients.patch

 rmk's pcmcia rework

+oops-counters.patch

 Display the oops instance in the oops record

+io_apic-DO_ACTION-cleanup.patch

 Clean up the IO APIC code.

+ext2-ext3-noatime-fix.patch

 Ext2 and ext3 inode flags initialisation fixes.





All 86 patches:

linus.patch
  Latest from Linus

mm.patch
  add -mmN to EXTRAVERSION

kgdb.patch

noirqbalance-fix.patch
  Fix noirqbalance

config_spinline.patch
  uninline spinlocks for profiling accuracy.

ppc64-reloc_hide.patch

ppc64-pci-patch.patch
  Subject: pci patch

ppc64-aio-32bit-emulation.patch
  32/64bit emulation for aio

ppc64-64-bit-exec-fix.patch
  Pass the load address into ELF_PLAT_INIT()

ppc64-scruffiness.patch
  Fix some PPC64 compile warnings

ppc64-compat-flock.patch
  compat_sys_fcntl{,64} 2/9 ppc64 part

ppc64-eeh-fix.patch
  ppc64 build fix

ppc64-socketcall-fix.patch

sym-do-160.patch
  make the SYM driver do 160 MB/sec

nfsd-disable-softirq.patch
  Fix race in svcsock.c in 2.5.61

report-lost-ticks.patch
  make lost-tick detection more informative

config-PAGE_OFFSET.patch
  Configurable kenrel/user memory split

ptrace-flush.patch
  cache flushing in the ptrace code

buffer-debug.patch
  buffer.c debugging

warn-null-wakeup.patch

ext3-truncate-ordered-pages.patch
  ext3: explicitly free truncated pages

reiserfs_file_write-5.patch

tcp-wakeups.patch
  Use fast wakeups in TCP/IPV4

lockd-lockup-fix-2.patch
  Subject: Re: Fw: Re: 2.4.20 NFS server lock-up (SMP)

rcu-stats.patch
  RCU statistics reporting

ext3-journalled-data-assertion-fix.patch
  Remove incorrect assertion from ext3

nfs-speedup.patch

nfs-oom-fix.patch
  nfs oom fix

sk-allocation.patch
  Subject: Re: nfs oom

nfs-more-oom-fix.patch

rpciod-atomic-allocations.patch
  Make rcpiod use atomic allocations

linux-isp.patch

isp-update-1.patch

remove-unused-congestion-stuff.patch
  Subject: [PATCH] remove unused congestion stuff

as-iosched.patch
  anticipatory I/O scheduler

as-debug-BUG-fix.patch

cfq-2.patch
  CFQ scheduler, #2

smalldevfs.patch
  smalldevfs

remap-file-pages-2.5.63-a1.patch
  Subject: [patch] remap-file-pages-2.5.63-A1

hugh-remap-fix.patch
  hugh's file-offset-in-pte fix

fremap-limit-offsets.patch
  fremap: limit remap_file_pages() file offsets

fremap-all-mappings.patch
  Make all executable mappings be nonlinear

filemap_populate-speedup.patch
  filemap_populate speedup

file-offset-in-pte-x86_64.patch
  x86_64: support for file offsets in pte's

file-offset-in-pte-ppc64.patch

objrmap-2.5.62-5.patch
  object-based rmap

objrmap-nonlinear-fixes.patch
  objrmap fix for nonlinear

scheduler-tunables.patch
  scheduler tunables

show_task-free-stack-fix.patch
  show_task() fix and cleanup

reiserfs-fix-memleaks.patch
  ReiserFS: fix memleaks on journal opening failures

yellowfin-set_bit-fix.patch
  yellowfin driver set_bit fix

htree-nfs-fix.patch
  Fix ext3 htree / NFS compatibility problems

update_atime-ng.patch
  inode a/c/mtime modification speedup

one-sec-times.patch
  Implement a/c/time speedup in ext2 & ext3

task_prio-fix.patch
  simple task_prio() fix

register-tty_devclass.patch
  Register tty_devclass before use

set_current_state-fs.patch
  use set_current_state in fs

set_current_state-mm.patch
  use set_current_state in mm

copy_thread-leak-fix.patch
  Fix memory leak in copy_thread

slab_store_user-large-objects.patch
  slab debug: perform redzoning against larger objects

file_list_lock-contention-fix.patch
  file_list_lock contention fixes

tty_files-fixes.patch
  file->f_list locking in tty_io.c

file_list_cleanup.patch
  file_list cleanup

file_list-remove-free_list.patch
  file_table: remove the private freelist

file-list-less-locking.patch
  file_list: less locking

vt_ioctl-stack-use.patch
  stack reduction in drivers/char/vt_ioctl.c

fix-mem-equals.patch
  Fix mem= options

no-mmu-stubs.patch
  a few missing stubs for !CONFIG_MMU

nommu-slab.patch
  slab changes for !CONFIG_MMU

nfsd-memleak-fix.patch
  nfsd/export.c memleak.

nfs-memleak-fix.patch
  memleak in fs/nfs/inode.c::nfs_get_sb()

ufs-memleak-fix.patch
  Memleak in fs/ufs/util.c

hugetlb-unmap_vmas-fix.patch
  fix the fix for unmap_vmas & hugepages

early-writeback-init.patch
  Early writeback initialisation

posix-timers-update.patch
  posix timers update

e100-memleak-fix.patch
  Memleak in e100 driver

bsd-printk-limit.patch

pcmcia-1-kill-get_foo_map.patch
  pcmcia: 1/6 kill get_*_map

pcmcia-2-remove-bus_foo-abstractions.patch
  pcmcia: 2/6: Remove bus_* abstractions

pcmcia-3-add-SOCKET_CARDBUS_CONFIG.patch
  pcmcia: 3/6: add SOCKET_CARDBUS_CONFIG flag

pcmcia-4-add-locking.patch
  pcmcia: 4/6: Add some locking to rsrc_mgr.c

pcmcia-5-add-CONFIG_PCMCIA_PROBE.patch
  pcmcia 5/6: Introduce CONFIG_PCMCIA_PROBE

pcmcia-6-remove-old-cardbus-clients.patch
  pcmcia: 6/6: Remove support for old cardbus clients

oops-counters.patch
  OOPS instance counters

io_apic-DO_ACTION-cleanup.patch
  io-apic.c: DO_ACTION cleanup

ext2-ext3-noatime-fix.patch
  Ext2/3 noatime and dirsync sometimes ignored



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>