Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Mon, 11 Sep 2000, Andrea Arcangeli wrote: > On Fri, 8 Sep 2000, Matthew Hawkins wrote: > >Something between bigmem and his big VM changes makes reiserfs > >uncompilable. [..] > > It's due LFS. Chris should have a reiserfs patch that compiles on top of > 2.2.18pre2aa2, right? (if not Chris, I can sure find it because the server > that was reproducing the DAC960 SMP lock inversion was running > 2.2.18pre2aa2+IKD on top of an huge reiserfs fs) the LFS patch is also incompatible with the NFSv3 patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Fri, 8 Sep 2000, Matthew Hawkins wrote: >Something between bigmem and his big VM changes makes reiserfs >uncompilable. [..] It's due LFS. Chris should have a reiserfs patch that compiles on top of 2.2.18pre2aa2, right? (if not Chris, I can sure find it because the server that was reproducing the DAC960 SMP lock inversion was running 2.2.18pre2aa2+IKD on top of an huge reiserfs fs) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
> > Andrea's. I've been patching most of them in for a while now simply > > because I've found my SMP system much more stable and useable. > > I also takled with Andrea and Alan about this. 2.2.16 will kill itself > within hours on my system. With Andrea's patches, it lives for long > times. I am slowly trickling them in as I get points I can be sure I can pin down problems the cause reliably. Andrea's patches tend to be far reaching in their effects and not always 100% obviously correct. Its the nature of fixing bugs in that kind of code - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
I hate to post just to say me too, but we couldn't run 2.2.16 for more than a few hours and even 2.2.17 would stop responding with a load average >200 right around the time of our heaviest usage and never come back. Assuming 2.2.18pre2aa2 doesn't crash in the next 2 weeks (the original problem we upgraded to fix) then we'll probably never change our kernel :) (and my associate who believes in windows won't have anything left to complain about). - Michael On Sun, 10 Sep 2000, Roeland Th. Jansen wrote: > On Thu, Sep 07, 2000 at 11:26:56PM +1100, Matthew Hawkins wrote: > > I'd like to advocate the inclusion of the majority of these patches of > > Andrea's. I've been patching most of them in for a while now simply > > because I've found my SMP system much more stable and useable. > > > I also takled with Andrea and Alan about this. 2.2.16 will kill itself > within hours on my system. With Andrea's patches, it lives for long > times. > > > -- > Grobbebol's Home | Don't give in to spammers. -o) > http://www.xs4all.nl/~bengel | Use your real e-mail address /\ > Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Thu, Sep 07, 2000 at 11:26:56PM +1100, Matthew Hawkins wrote: > I'd like to advocate the inclusion of the majority of these patches of > Andrea's. I've been patching most of them in for a while now simply > because I've found my SMP system much more stable and useable. I also takled with Andrea and Alan about this. 2.2.16 will kill itself within hours on my system. With Andrea's patches, it lives for long times. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Thu, Sep 07, 2000 at 11:26:56PM +1100, Matthew Hawkins wrote: I'd like to advocate the inclusion of the majority of these patches of Andrea's. I've been patching most of them in for a while now simply because I've found my SMP system much more stable and useable. I also takled with Andrea and Alan about this. 2.2.16 will kill itself within hours on my system. With Andrea's patches, it lives for long times. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
I hate to post just to say me too, but we couldn't run 2.2.16 for more than a few hours and even 2.2.17 would stop responding with a load average 200 right around the time of our heaviest usage and never come back. Assuming 2.2.18pre2aa2 doesn't crash in the next 2 weeks (the original problem we upgraded to fix) then we'll probably never change our kernel :) (and my associate who believes in windows won't have anything left to complain about). - Michael On Sun, 10 Sep 2000, Roeland Th. Jansen wrote: On Thu, Sep 07, 2000 at 11:26:56PM +1100, Matthew Hawkins wrote: I'd like to advocate the inclusion of the majority of these patches of Andrea's. I've been patching most of them in for a while now simply because I've found my SMP system much more stable and useable. I also takled with Andrea and Alan about this. 2.2.16 will kill itself within hours on my system. With Andrea's patches, it lives for long times. -- Grobbebol's Home | Don't give in to spammers. -o) http://www.xs4all.nl/~bengel | Use your real e-mail address /\ Linux 2.2.16 SMP 2x466MHz / 256 MB |on Usenet. _\_v - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Fri, 8 Sep 2000, Matthew Hawkins wrote: Something between bigmem and his big VM changes makes reiserfs uncompilable. [..] It's due LFS. Chris should have a reiserfs patch that compiles on top of 2.2.18pre2aa2, right? (if not Chris, I can sure find it because the server that was reproducing the DAC960 SMP lock inversion was running 2.2.18pre2aa2+IKD on top of an huge reiserfs fs) Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On 2000-09-07 22:39:55 +0100, Alan Cox wrote:
> > Andrea VM patches will be included in 2.2.18.
>
> We'll see
Something between bigmem and his big VM changes makes reiserfs
uncompilable. I stay with the stock VM and its only under significant
load that it falls over and starts messing with the smooth continuity of
X pointer movement and mp3 decoding.
Surely though I can't be the only person with an SMP system experiencing
the pointless cpu chewing while idle without Marcelo's sync_page_buffers()
fix? Again, Andrea's SMP patches are worth a look too as most of them are
so simple even I can see they make sense. No problems yet on a UP
system with them patched in either.
--
* Matthew Hawkins <[EMAIL PROTECTED]> :(){ :|:&};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
> Andrea VM patches will be included in 2.2.18. We'll see > They are not included yet because Alan does not want two untested changes > together in the same kernel (2.2.18pre3 has ext2 patches). Right now I dont want to mix VM changes with the ext2 fixups and the large amount of driver work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Thu, 7 Sep 2000, Matthew Hawkins wrote: > > I'd like to advocate the inclusion of the majority of these patches of > Andrea's. I've been patching most of them in for a while now simply > because I've found my SMP system much more stable and useable. Andrea VM patches will be included in 2.2.18. They are not included yet because Alan does not want two untested changes together in the same kernel (2.2.18pre3 has ext2 patches). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Thu, 7 Sep 2000, Boszormenyi Zoltan wrote: >It contains code in arch/i386/mtrr.c that looks pretty much like >my "64 bit MTRR" patch that was posted on lkml some time last year >and makes use of the full 36 bit MTRR address and size on Intel and >44 bits on AMD Athlon. BTW my patch contained some new ioctls >which exports this capability to user space... Correct, it handles the full 36bit MTRR. I received the patch from David Wragg <[EMAIL PROTECTED]> a few months ago claiming it was fixing a problem with bigmem (however bigmem handle at max 4G, thus I guess it would fix problems also for the stock kernel on machines with more than 4G, but of course if you have more than 4G and you run 2.2.x you're for sure using bigmem :). While sending me the patch David Wragg told me: "... Mark Vojkovich at VA Linux found the problem. ..." Then I checked the patch with the reference manual at hand, it was correct and I included it into the bigmem patch as a bugfix. >Which of the smaller patches contain this code? bigmem. >Your comments do not describe this particular piece of code. I'll try to rember to mention this particular bugfix in bigmem in the future. If you were the author let me know and I'll add your name (however you should check with David, they may have implemented it indipendently). I sure _want_ to give credits to people who deserves them so I appreciate the clarification. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
I'd like to advocate the inclusion of the majority of these patches of
Andrea's. I've been patching most of them in for a while now simply
because I've found my SMP system much more stable and useable.
Distinctly lacking from the 2.2.17 release was Marcelo Tosatti's age-old
1-character fix to sync_page_buffers() without which my system is unusable.
(namely, doing WRITEA in the call to ll_rw_block()). Andrea provides a
similar and cleaner implementation of the entire sync_page_buffers()
function which also works fine.
Debate the more ambitious patches he proposes all you like, all I care
about is the SMP fixes / improvements and the fact that I don't have to
put up with both cpu's going flat out even when the system is, from a
user's perspective, idle. I don't use initrd, have an AXP (worse luck),
use >2Gb files or LVM. Although having a 2.3 compatible LVM would not
go astray for a 2.2.x-lmp :)
*clink clink*
--
* Matthew Hawkins <[EMAIL PROTECTED]> :(){ :|:&};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Wed, 6 Sep 2000, Andrea Arcangeli wrote: > The 2.2.18pre2aa1 patch is here: > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18pre2aa2.bz2 It contains code in arch/i386/mtrr.c that looks pretty much like my "64 bit MTRR" patch that was posted on lkml some time last year and makes use of the full 36 bit MTRR address and size on Intel and 44 bits on AMD Athlon. BTW my patch contained some new ioctls which exports this capability to user space... Which of the smaller patches contain this code? Your comments do not describe this particular piece of code. Regards, Zoltan Boszormenyi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Wed, 6 Sep 2000, Andrea Arcangeli wrote: The 2.2.18pre2aa1 patch is here: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.2/2.2.18pre2aa2.bz2 It contains code in arch/i386/mtrr.c that looks pretty much like my "64 bit MTRR" patch that was posted on lkml some time last year and makes use of the full 36 bit MTRR address and size on Intel and 44 bits on AMD Athlon. BTW my patch contained some new ioctls which exports this capability to user space... Which of the smaller patches contain this code? Your comments do not describe this particular piece of code. Regards, Zoltan Boszormenyi [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
I'd like to advocate the inclusion of the majority of these patches of
Andrea's. I've been patching most of them in for a while now simply
because I've found my SMP system much more stable and useable.
Distinctly lacking from the 2.2.17 release was Marcelo Tosatti's age-old
1-character fix to sync_page_buffers() without which my system is unusable.
(namely, doing WRITEA in the call to ll_rw_block()). Andrea provides a
similar and cleaner implementation of the entire sync_page_buffers()
function which also works fine.
Debate the more ambitious patches he proposes all you like, all I care
about is the SMP fixes / improvements and the fact that I don't have to
put up with both cpu's going flat out even when the system is, from a
user's perspective, idle. I don't use initrd, have an AXP (worse luck),
use 2Gb files or LVM. Although having a 2.3 compatible LVM would not
go astray for a 2.2.x-lmp :)
*clink clink*
--
* Matthew Hawkins [EMAIL PROTECTED] :(){ :|:};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Thu, 7 Sep 2000, Boszormenyi Zoltan wrote: It contains code in arch/i386/mtrr.c that looks pretty much like my "64 bit MTRR" patch that was posted on lkml some time last year and makes use of the full 36 bit MTRR address and size on Intel and 44 bits on AMD Athlon. BTW my patch contained some new ioctls which exports this capability to user space... Correct, it handles the full 36bit MTRR. I received the patch from David Wragg [EMAIL PROTECTED] a few months ago claiming it was fixing a problem with bigmem (however bigmem handle at max 4G, thus I guess it would fix problems also for the stock kernel on machines with more than 4G, but of course if you have more than 4G and you run 2.2.x you're for sure using bigmem :). While sending me the patch David Wragg told me: "... Mark Vojkovich at VA Linux found the problem. ..." Then I checked the patch with the reference manual at hand, it was correct and I included it into the bigmem patch as a bugfix. Which of the smaller patches contain this code? bigmem. Your comments do not describe this particular piece of code. I'll try to rember to mention this particular bugfix in bigmem in the future. If you were the author let me know and I'll add your name (however you should check with David, they may have implemented it indipendently). I sure _want_ to give credits to people who deserves them so I appreciate the clarification. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On Thu, 7 Sep 2000, Matthew Hawkins wrote: I'd like to advocate the inclusion of the majority of these patches of Andrea's. I've been patching most of them in for a while now simply because I've found my SMP system much more stable and useable. Andrea VM patches will be included in 2.2.18. They are not included yet because Alan does not want two untested changes together in the same kernel (2.2.18pre3 has ext2 patches). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre2aa2 and patches for 2.2.18pre3
On 2000-09-07 22:39:55 +0100, Alan Cox wrote:
Andrea VM patches will be included in 2.2.18.
We'll see
Something between bigmem and his big VM changes makes reiserfs
uncompilable. I stay with the stock VM and its only under significant
load that it falls over and starts messing with the smooth continuity of
X pointer movement and mp3 decoding.
Surely though I can't be the only person with an SMP system experiencing
the pointless cpu chewing while idle without Marcelo's sync_page_buffers()
fix? Again, Andrea's SMP patches are worth a look too as most of them are
so simple even I can see they make sense. No problems yet on a UP
system with them patched in either.
--
* Matthew Hawkins [EMAIL PROTECTED] :(){ :|:};:
** Information Specialist, tSA Group Pty. Ltd. Ph: +61 2 6257 7111
*** 1 Hall Street, Lyneham ACT 2602 Australia. Fx: +61 2 6257 7311
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.2.18pre2aa2 and patches for 2.2.18pre3
The main features of 2.2.18pre2aa2 are: o Support for 4Gigabyte of RAM on IA32 (me and Gerhard Wichert) o Support for 2T of RAM on alpha (me) o Improved VM for high end machines with enough ram and doing heavy I/O under high memory pressure plus fixes for the MAP_SHARED oom by killing kpiod. (me) o RAW-IO (doable with bigmem enabled too). (Stephen C. Tweedie) o SMP scheduler improvements. (me and partly from 2.3.x contributed by Ingo Molnar) o LFS (>2G file on 32bit architectures) o misc fixes Detailed description of 2.2.18pre2aa2 follows. --- 00_4_min_percent-1 Increase the min percent of the buffer cache and page cache to 4%. (it wouldn't matter if the VM algorithms were better). (me) 00_IO-wait-2.gz Avoid suprious unplug of the I/O queue. (me) 00_SMP-scheduler-2.2.14-G.gz Better SMP reschedule_idle. (partly backported from 2.3.x, 2.3.x version was contributed by Ingo Molnar) 00_account-failed-buffer-tries-1 Account also the failed buffer tries during shrink_mmap. (me) 00_alpha-epoch-1 Put in sync the RTC parsing done by the kernel at boot while setting the system time, with the parsing done by the RTC driver during initialization. (Jan-Benedict Glaw <[EMAIL PROTECTED]> fixed it in 2.4.x) 00_alpha-read-unlock-SMP-race-1 SMP race fix in the read_unlock implementation of alpha. (me) 00_buf-run_task_queue.gz Avoid suprious unplug of the I/O queue. (me) 00_delack-timer-5.gz Additional paranoid stuff in TCP delayed acks code (if somebody can still reproduce lockups under heavy TCP load, the delack-timer-5 patch can be the solution). In 2.2.15 only what it was obviously wrong is been fixed, but at the time I did delack-timer-5 I was convinced the stuff in 2.2.15 _might_ not be enough, so if you have still lockups under 2.2.15 let us know. delack-timer-5 is reported to definitely fix the TCP lockup. (me) 00_elv-simple-latency-1 It simplify the elevator algorithm to remove the careful code that was accounting also the place in the queue where the request was inserted while setting its initial latency. This changed makes the systems much less interactive, but it fixes the tiotest numbers of course still avoiding indefinite starvation as it was happeneing before the elevator rewrite. (me, tested also by Jens Axboe) 00_inode-cleanup-3.gz Minor inode stuff cleanedup. (me) 00_java-proc.gz Revertd the semantic change that make differences between /proc/0$$ and /proc/$$, this allows backwards compatibilty of a misfeature and it _won't_ hurt security. There's no downside in reverting the 2.2.13 semantic change. 00_kupdate-sigstop-2.2.11-1.gz Allows kupdate to be stopped via SIGSTOP (currently it must be stopped by setting interval to zero via sysctl). This returns useful in the airplane where you do killall -STOP kupdate... STOP kupdate at your own risk of course ;) (me) 00_mremap-waste-virtual-stack-space-1.gz Avoids mremap to grow in virtual addresses (and so in turn it avoids to waste virtual address space). 00_nanosleep-4.gz Provide nanosleep usec resolution so that a signal flood doesn't hang glibc folks that correctly trust the rem field to resume the nanosleep after a syscall interruption. (without the patch nanosleep resolution is instead 10msec on IA32 and around 1msec on alpha) (me) 00_overcommit-1.gz Make sure to not understimate the available memory (the cache and buffers may be under the min percent) (me) 00_set_rtc_mss-SMP-race-1.gz Fix set_rtc_mss SMP race between timer irq and rtc irq. (me) 00_silent-stack-overflow-4.gz Avoid stack to silenty overflow on the heap (make life easier to track down userspace issues). Perfect approch is not possible even using special LDT for the stack segment. The approch in the patch will work 99% of the time and it enforces a GAP between heap and stack of 1 page as default (configurable via sysctl, if turned to zero the feature is disabled completly). (me) 00_slow-gtod-SMP-race-1.gz Fixes an SMP race in slow gettimeofday. (me) 00_stod-lost_ticks-1.gz Check lost_ticks in settimeofday to be more precise. 00_tsc-calibration-non-compile-time-1.gz TSC calibration must be dynamic and not a compile time thing because gettimeofday is dynamic and it depends on the TSCs to be in sync. (me) 00_version Change to the Makefile EXTRAVERSION. 10_bigmem-2.2.18pre2-18.bz2 BIGMEM production code (IA32 and alpha). This one fixes a memory
