2.4.22pre6aa1

URL:

	http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.22pre6aa1.gz

changelog diff between 2.4.21rc8aa1 and 2.4.22pre6aa1:

Only in 2.4.21rc8aa1: 00_01_cciss-1
Only in 2.4.21rc8aa1: 00_02_cciss-1
Only in 2.4.21rc8aa1: 00_03_cciss-1

Updates are in mainline.

Only in 2.4.21rc8aa1: 00_backout-irda-trivial-1

Somebody acknowledged and fixed the breakage properly. I hadn't a chance to test it myself yet on my cellphone, but I will shortly.

Only in 2.4.21rc8aa1: 00_binfmt-elf-checks-1 Only in 2.4.22pre6aa1: 00_binfmt-elf-checks-2 Only in 2.4.21rc8aa1: 00_dirty-inode-1
Only in 2.4.22pre6aa1: 00_dirty-inode-3
Only in 2.4.21rc8aa1: 00_drop-inetpeer-cache-4.gz Only in 2.4.22pre6aa1: 00_drop-inetpeer-cache-5.gz Only in 2.4.21rc8aa1: 00_ext3-register-filesystem-lifo-1 Only in 2.4.22pre6aa1: 00_ext3-register-filesystem-lifo-2 Only in 2.4.21rc8aa1: 00_extraversion-24
Only in 2.4.22pre6aa1: 00_extraversion-26
Only in 2.4.21rc8aa1: 00_generic_file_write_nolock-1 Only in 2.4.22pre6aa1: 00_generic_file_write_nolock-3 Only in 2.4.21rc8aa1: 00_module-locking-fix-2 Only in 2.4.22pre6aa1: 00_module-locking-fix-3 Only in 2.4.21rc8aa1: 00_netconsole-2.4.10-C2-3.gz Only in 2.4.22pre6aa1: 00_netconsole-2.4.10-C2-4.gz Only in 2.4.21rc8aa1: 00_rwsem-fair-36
Only in 2.4.21rc8aa1: 00_rwsem-fair-36-recursive-8 Only in 2.4.22pre6aa1: 00_rwsem-fair-38
Only in 2.4.22pre6aa1: 00_rwsem-fair-38-recursive-8 Only in 2.4.21rc8aa1: 00_setfl-race-fix-2
Only in 2.4.22pre6aa1: 00_setfl-race-fix-3
Only in 2.4.21rc8aa1: 00_vm-cleanups-2
Only in 2.4.22pre6aa1: 00_vm-cleanups-3
Only in 2.4.21rc8aa1: 05_vm_20_cleanups-2
Only in 2.4.22pre6aa1: 05_vm_20_cleanups-3
Only in 2.4.21rc8aa1: 07_qlogicfc-4.gz
Only in 2.4.22pre6aa1: 07_qlogicfc-5.gz
Only in 2.4.21rc8aa1: 10_rawio-vary-io-18
Only in 2.4.22pre6aa1: 10_rawio-vary-io-21
Only in 2.4.21rc8aa1: 20_rcu-poll-8
Only in 2.4.22pre6aa1: 20_rcu-poll-9
Only in 2.4.21rc8aa1: 20_sched-o1-fixes-8
Only in 2.4.22pre6aa1: 20_sched-o1-fixes-9
Only in 2.4.21rc8aa1: 50_uml-patch-2.4.20-5-1.gz Only in 2.4.22pre6aa1: 50_uml-patch-2.4.20-5-2.gz Only in 2.4.21rc8aa1: 60_atomic-lookup-5
Only in 2.4.22pre6aa1: 60_atomic-lookup-6
Only in 2.4.21rc8aa1: 60_tux-exports-6
Only in 2.4.22pre6aa1: 60_tux-exports-7
Only in 2.4.21rc8aa1: 70_delalloc-2
Only in 2.4.22pre6aa1: 70_delalloc-3
Only in 2.4.21rc8aa1: 96_inode_read_write-atomic-6 Only in 2.4.22pre6aa1: 96_inode_read_write-atomic-8 Only in 2.4.21rc8aa1: 97_i_size-corruption-fixes-2 Only in 2.4.22pre6aa1: 97_i_size-corruption-fixes-4 Only in 2.4.21rc8aa1: 9900_aio-20.gz
Only in 2.4.22pre6aa1: 9900_aio-21.gz
Only in 2.4.22pre6aa1: 9920_kgdb-10.gz
Only in 2.4.21rc8aa1: 9920_kgdb-8.gz
Only in 2.4.21rc8aa1: 9925_kmsgdump-0.4.4-2.gz Only in 2.4.22pre6aa1: 9925_kmsgdump-0.4.4-3.gz Only in 2.4.21rc8aa1: 9930_io_request_scale-5 Only in 2.4.22pre6aa1: 9930_io_request_scale-6 Only in 2.4.22pre6aa1: 9985_blk-atomic-12
Only in 2.4.21rc8aa1: 9985_blk-atomic-9
Only in 2.4.21rc8aa1: 9996_kiobuf-slab-1
Only in 2.4.22pre6aa1: 9996_kiobuf-slab-2
Only in 2.4.21rc8aa1: 9998_lowlatency-fixes-12 Only in 2.4.22pre6aa1: 9998_lowlatency-fixes-13 Only in 2.4.21rc8aa1: 9999_dm-1
Only in 2.4.22pre6aa1: 9999_dm-2
Only in 2.4.21rc8aa1: 9999_gcc-3.3-6
Only in 2.4.22pre6aa1: 9999_gcc-3.3-7
Only in 2.4.21rc8aa1: 9999_sched_yield_scale-2 Only in 2.4.22pre6aa1: 9999_sched_yield_scale-5

Rediffed.

Only in 2.4.22pre6aa1: 00_copy-namespace-1

Fix copy-namespace.

Only in 2.4.21rc8aa1: 00_cpufreq-1

Dropped (would better go in mainline than in -aa, I already tried it and it doesn't do what I need, and now it's rejecting in multiple ways).

Only in 2.4.22pre6aa1: 00_crc-makefile-clean-1

Remeber to delete the autogenerated files to generate clean diffs.

Only in 2.4.21rc8aa1: 00_cs46xx-u32-1
Only in 2.4.21rc8aa1: 00_floppy-smp-race-and-queuesize-1 Only in 2.4.21rc8aa1: 00_ipv6-route-fix-1
Only in 2.4.21rc8aa1: 00_o_direct-b_page-null-1 Only in 2.4.21rc8aa1: 00_ppp-ioctl-memleak-1 Only in 2.4.21rc8aa1: 00_tcp-tw-death-2
Only in 2.4.21rc8aa1: 00_usbnet-zaurus-c700-1 Only in 2.4.21rc8aa1: 00_wait_kio-cleanup-1 Only in 2.4.21rc8aa1: 10_tlb-state-3
Only in 2.4.21rc8aa1: 30_02_call-reserve1-1 Only in 2.4.21rc8aa1: 30_03_call-reserve2-2 Only in 2.4.21rc8aa1: 30_04_noac-1
Only in 2.4.21rc8aa1: 30_09_o_direct-3
Only in 2.4.21rc8aa1: 30_10-lockd1-1
Only in 2.4.21rc8aa1: 30_11-lockd2-1
Only in 2.4.21rc8aa1: 30_13-lockd4-1
Only in 2.4.21rc8aa1: 30_15-xprt_fixes-1
Only in 2.4.21rc8aa1: 70_quota-backport-3
Only in 2.4.21rc8aa1: 9999901_O_DIRECT-1

Merged in mainline.

Only in 2.4.22pre6aa1: 00_elevator-lowlatency-1

Reduced the number of requests during seeks (the latency times increased slightly during seeks with pre5/pre6).

Only in 2.4.22pre6aa1: 00_elevator-read-reservation-axboe-2l-1

Incremental patch from Jens, that reserved some spare request for reads. This is been measured to avoid some waiting for reads and it's beneficial in the common case.

Only in 2.4.22pre6aa1: 00_fdatasync-cleanup-1

Avoid a compile time warning.

Only in 2.4.21rc8aa1: 00_ksoftirqd-max-loop-networking-1 Only in 2.4.22pre6aa1: 00_ksoftirqd-max-loop-networking-2

Merged a fix from Philip Craig to be sure to make
the anti-DoS logic effective. He wrote and verified the code. It makes perfect sense so it's applied. Normal usages shouldn't notice the difference, especially with the max-loop logic.

Only in 2.4.22pre6aa1: 00_parport-multi-io-pci-1

Multi-io cards depends on config-pci, from Matthew Bell.

Only in 2.4.21rc8aa1: 00_radeon-3

This started to reject and the mainline code seems slightly different now. Should be rechecked later.

Only in 2.4.21rc8aa1: 00_sched-O1-aa-2.4.19rc3-12.gz Only in 2.4.22pre6aa1: 00_sched-O1-aa-2.4.19rc3-14.gz

Avoid losing an half timeslice of in signal delivery delay if the signal was sent while the task was under weakup. Fix from Ingo Molnar.

Only in 2.4.21rc8aa1: 00_semop-timeout-2
Only in 2.4.22pre6aa1: 00_semop-timeout-3

Most of it merged in mainline, except the ia64 entry in the syscall table. Interestingly the syscall now allocated for ia64 is different than the one in 21rc8aa1.

Only in 2.4.21rc8aa1: 00_smp-timers-not-deadlocking-3 Only in 2.4.22pre6aa1: 00_smp-timers-not-deadlocking-5

Merged an anti deadlock fix from lcm, 2.5 probably needs it too. In short the theory that mod_timer is the only thing that can run in parallel was wrong, add_timer and del_timer/del_timer_sync can too. Having already fixed mod_timer in a backwards compatible way before merging the smp-timers in -aa, made it easy to fix those further windows too.

Only in 2.4.21rc8aa1: 00_usb_get_string-len-1

Dropped, was the wrong fix and it could break stuff.

Only in 2.4.22pre6aa1: 05_vm_25_try_to_free_buffers-invariant-1

Minor cleanup from Daniele Bellucci.

Only in 2.4.21rc8aa1: 10_o_direct-open-check-3
Only in 2.4.22pre6aa1: 10_o_direct-open-check-4

Updated to handle the double API.

Only in 2.4.21rc8aa1: 10_try-cciss-only-4G-1

Dropped, new code in mainline.

Only in 2.4.22pre6aa1: 21_ppc64-aa-2

Was used to fix ppc64 around pre3, but pre3-pre6 may have broke stuff again, I didn't check.

Only in 2.4.21rc8aa1: 70_xfs-1.2-3.gz
Only in 2.4.22pre6aa1: 70_xfs-1.3-2.gz
Only in 2.4.21rc8aa1: 70_xfs-config-stuff-3
Only in 2.4.22pre6aa1: 70_xfs-config-stuff-4
Only in 2.4.21rc8aa1: 70_xfs-exports-1
Only in 2.4.22pre6aa1: 70_xfs-exports-2
Only in 2.4.21rc8aa1: 70_xfs-sysctl-2
Only in 2.4.22pre6aa1: 70_xfs-sysctl-3
Only in 2.4.21rc8aa1: 71_posix_acl-2
Only in 2.4.22pre6aa1: 71_posix_acl-3
Only in 2.4.22pre6aa1: 71_xfs-VM_IO-1
Only in 2.4.21rc8aa1: 71_xfs-aa-2
Only in 2.4.22pre6aa1: 71_xfs-aa-4
Only in 2.4.22pre6aa1: 71_xfs-fixup-1
Only in 2.4.22pre6aa1: 71_xfs-infrastructure-1
Only in 2.4.22pre6aa1: 71_xfs-tuning-1

Upgraded XFS from 1.2 to 1.3.

Only in 2.4.21rc8aa1: 80_x86_64-common-code-6
Only in 2.4.21rc8aa1: 82_x86_64-suse-12
Only in 2.4.21rc8aa1: 84_x86-64-arch-3
Only in 2.4.21rc8aa1: 85_x86-64-includes-2

Dropped, mainline is more uptodate. Though it won't compile like ia64.

Only in 2.4.21rc8aa1: 93_NUMAQ-10
Only in 2.4.22pre6aa1: 93_NUMAQ-13

Merged latest numa code for x440.

Only in 2.4.22pre6aa1: 9900_aio-21-ppc-1

ppc aio code.

Only in 2.4.22pre6aa1: 9901_aio-blkdev-1

Allow aio on blkdevices too (dunno who wrote this).

Only in 2.4.21rc8aa1: 9910_shm-largepage-13.gz
Only in 2.4.22pre6aa1: 9910_shm-largepage-16.gz

Thanks to Hugh for the help in porting the bigpages
to the rewritten shmfs layer in 22pre. No idea at the moment if it works or if it only compiles.

Only in 2.4.21rc8aa1: 9940_ocfs-2.gz
Only in 2.4.22pre6aa1: 9940_ocfs-3.gz
Only in 2.4.21rc8aa1: 9941_ocfs-20021012.gz
Only in 2.4.22pre6aa1: 9941_ocfs-direct-1
Only in 2.4.22pre6aa1: 9941_ocfs-warnings-1
Only in 2.4.21rc8aa1: 9942_ocfs-compile-2
Only in 2.4.22pre6aa1: 9942_ocfs-o_direct-API-1

Upgraded to a more recent ocfs version (merged by Andi Kleen).

Only in 2.4.21rc8aa1: 9980_fix-pausing-5
Only in 2.4.22pre6aa1: 9980_fix-pausing-6
Only in 2.4.21rc8aa1: 9981_elevator-lowlatency-5

Fix pausing and elevator lowlatency are now in 2.4.22pre.

Unplugging the queue may avoid a reschedule.

Only in 2.4.21rc8aa1: 9986_elevator-merge-fast-path-1 Only in 2.4.22pre6aa1: 9986_elevator-merge-fast-path-2

Enabled for headactive devices (i.e. IDE) too. Idea and original patch from Daniele Bellucci, final patch from Jens Axboe.

Only in 2.4.22pre6aa1: 9998_lowlatency-reiserfs-1

Added an appealing reschedule hook (should be double checked).

Only in 2.4.22pre6aa1: 9999900_desktop-2

Added a desktop mode that guarantees an higher degree of fariness in the scheduler.

Only in 2.4.22pre6aa1: 9999900_drm-4.3-1.gz

drm updates. Merged by Chip Salzenberg.

Only in 2.4.22pre6aa1: 9999900_ecc-20020904-1.gz

ecc timer poller latest code. Merged by Chip Salzenberg.

Only in 2.4.21rc8aa1: 9999900_ikd-1
Only in 2.4.22pre6aa1: 9999900_ikd-2.gz

Initialize it at boot so it will have a chance to work.

Only in 2.4.22pre6aa1: 9999900_x86-movsl-copy-user-1

Boost the copy-user asm.

Only in 2.4.21rc8aa1: 9999_truncate-nopage-race-1 Only in 2.4.22pre6aa1: 9999_truncate-nopage-race-3

Take advantage of the i_alloc_sem in read mode to serialize only against truncates, to avoid possible suprious reschedules.

Only in 2.4.21rc8aa1: 10_ext3-o_direct-2
Only in 2.4.22pre6aa1: 10_ext3-o_direct-3
Only in 2.4.21rc8aa1: 40_o_direct-reiserfs-2

Update to new API.

Andrea

Hi Andrea.

I am sorry, I couldn't find this file.
Maybe, I have to wait ?

From: Andrea Arcangeli <[email protected]>
Subject: 2.4.22pre6aa1
Date: Thu, 17 Jul 2003 12:28:57 +0200

On Thursday 17 July 2003 12:42, ooyama eiichi wrote:

Hi Ooyama,

use another mirror, e.g:
http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.22pre6aa1.gz

ciao, Marc

Hi,Andrea.

I can get the file from this URL: (without "us")
http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.22pre6aa1.gz

Proposed for 2.4.23. Marcelo doesn't seem to have any objections.

You know where to report bugs...

Dave

Hmm I thought it was a feature not a bug or I would have already reported something ;)

What I need is to set the frequency to around 400mhz when on battery, but that's not any of the speedstep frequencies, the speedstep frequencies are too fast (750/1200mhz) or too slow (250mhz). Is it supposed to work that way?

thanks,

Andrea

On Thursday 17 July 2003 12:28, Andrea Arcangeli wrote:

Hi Andrea,

Hmm, this is now my first day testing out .22-pre6 and .22-pre6aa1 with the new I/O stall fixes. At a first look & feel it's very good, but I've noticed a side effect (if it can be called so):

VMware4 Workstation
-------------------

2.4.22-pre[6|6aa1]: ~ 1 minute 02 seconds from: Start this virtual machine ...
2.4.22-pre2 : ~ 30 seconds from: Start this virtual machine ...

... to start up Windows 2000 Professional completely.

Well, personally I don't care about the slowdown of vmware startup with a VM but there may be many other slowdows?!

ciao, Marc

can you check what's doing? reading or writing? I guess it's a kind of workload that would seek all over the place. However throughput should be better with seeks now since I could grow the queue (if something only latency would be worse but the above is a throughput thing only, latency doesn't matter).

Can you retry once more time with pre2 vs pre6 to be 100% sure it's reproducible?

thanks,

Andrea

Can you try a stock -pre kernel, say pre[256], and see where the additional time starts?

On Friday 18 July 2003 00:27, Mike Fedyk wrote:

Hi Mike,

Sure. Well, but I expect the behaviour starts with -pre3.

Anyway, I'll test.

ciao, Marc

hmmm:

2.4.22-pre[6|6aa1]:
-------------------
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072 131072+0 records in
131072+0 records out
2147483648 bytes transferred in 128.765686 seconds (16677453 bytes/sec)

2.4.22-pre2:
------------
root@codeman:[/] # dd if=/dev/zero of=/home/largefile bs=16384 count=131072 131072+0 records in
131072+0 records out
2147483648 bytes transferred in 98.489331 seconds (21804226 bytes/sec)

both kernels freshly rebooted.

Machine:
--------
Celeron 1,3GHz
512MB RAM
2x IDE (UDMA100) 60/40 GB
1GB SWAP, 512MB on each disk (same priority)
ext3fs (data=ordered)
XFree 4.3
WindowMaker 0.82-CVS

ciao, Marc

this explains it.

Can you try to change include/linux/blkdev.h like this:

-#define MAX_QUEUE_SECTORS (4 << (20 - 9)) /* 4 mbytes when full sized */ +#define MAX_QUEUE_SECTORS (16 << (20 - 9)) /* 4 mbytes when full sized */

This will raise the queue from 4 to 16M. That is the first(/only) thing that can explain a drop in performnace while doing contigous I/O. However I didn't expect it to make a difference, or at least not so relevant.

If this doesn't help at all, it might not be an elevator/blkdev thing. At least on my machines the contigous I/O still at the same speed.

You also where the only one reporting a loss of performance with elevator-lowlatency, it could be still the same problem that you've seen at that time.

Last but not the least, if it's an elevator/blkdev thing, you must be able to measure it with reads too, not only with writes. Can you try to read that file back? (careful about the cache effects if you read it multiple times and you interrupt it, best it to benchmark reads after a mount to be sure)

can you try with data=writeback (or ext2) or hdparm -W1 and see if you can still see the same delta between the two kernels? (careful with -W1 as it invalidates journaling)

thanks,

Andrea

Especially with just one writer, you really shouldn't be able to see a difference in pre6. Did you measure this change on both pre6 and pre6aa1. Your message indicated that but I wanted to double check to make sure.

-chris

On Friday 18 July 2003 02:30, Chris Mason wrote:

Hi Chris,

Yes, I measured it with pre6 and pre6aa1. There is no noticable difference.

ciao, Marc

this makes sense, thanks for double checking.

Andrea

Just to be 100% sure I run an accurate benchmarks myself too. I had the numbers for the pre-2.4.22pre levels, but I didn't benchmarked yet on the final code in mainline that had some cosmetical difference.

These are the results for the contigous I/O with vanilla 2.4.21 against vanilla 2.4.22-pre6 against 2.4.22pre6aa2 (and aa2 is completely equal to aa1 in terms of blkdev/IO). BTW, pre6aa2 is configured as desktop so it has some additional overhead (not significant in pure I/O bound computatations).

aic7xxx booted with mem=128m ext3 data=ordered

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Kernel     MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
2.4.21    100 11052 77.3 21683 15.5 16401  8.8 20347 82.1 32765  6.1 865.6  2.8
2.4.21    100 13533 94.5 21236 13.9 15904  7.9 21182 82.3 35019  5.1 1254.3  2.2
2.4.21    100 12402 86.5 22453 14.9 16165  5.8 20270 82.1 34754  6.4 1398.8  3.8

22pre6    100 13070 91.4 23314 15.3 15402  6.5 21202 81.8 33167  8.4 959.9  2.2
22pre6    100 13181 92.2 18556 12.5 16506  6.9 20562 78.1 33394  4.9 1271.9  1.9
22pre6    100 14082 98.5 23170 16.1 16199  5.7 21045 81.2 34124  7.3 1450.6  4.0

22pre6aa2 100 12703 90.5 23245 16.3 15533  6.8 19730 79.6 37072  8.0 775.9  1.4
22pre6aa2 100 13241 94.0 20602 14.4 15562  7.0 19675 79.6 37102  7.7 843.5  1.8
22pre6aa2 100 12948 93.0 21566 15.0 15970  7.6 19460 81.7 36599  7.2 740.6  1.7

as you can see for contigous I/O I can't measure any regression at all, the minor variations across the three runs are likely for the largest part influenced by the ext3 block allocation that can change for every run.

Andrea

On Friday 18 July 2003 00:50, Andrea Arcangeli wrote:

Hi Andrea,

well, it doesn't help at all. I/O gets more worse with that change. (8mb/s less). How can this happen? *wondering*

The only one? Surely not. Also Con tested your elevator-lowlatency and we both saw performance degration :)

Yes, I'll do it later this day.

Sorry for my late reply. I've been very busy.

ciao, Marc

performance degradation when? note that we're only talking about contigous I/O here, not contest. I can't measure any performance degradation during contigous I/O and if something it could be explained by the now shorter queue, but you tried enlarging it and it went even slower (this was good btw, confirming a larger queue was completely worthless and it only hurts the VM without providing any I/O bandwidth pipelining benefit). The elevator-lowlatency should have no other effect other than a shorter queue during pure contigous I/O.

please try plain ext2, this sounds like some fs effect of some sort. The fs must throttle on the shorter queue or seek differently somehow.

No problem ;)

Andrea

On Tuesday 22 July 2003 15:59, Andrea Arcangeli wrote:

Hi Andrea,

Well, contigous I/O isn't a big problem, though I saw performance degradation in contigous I/O. The problem is, that I still see mouse stops while heavy I/O, that I still see keyboard stops while heavy I/O, X is dog slow while heavy I/O (renicing X to -20 doesn't really help). I really miss the 2.4.18 time where this wasn't a problem at all!
Contest was not the reason. An easy reproducable scenario is:

dd if=/dev/zero of=/home/largefile bs=16384 count=131072

This will kill your mouse, keyboard and X. The only "workaround" not to see mouse stops, keyboard stops and X dogstyle was decreasing nr_requests from 128 to 4. Anything higher resulted in pauses (e.g. 8 for nr_requests). Maybe SCSI behaves totally different, dunno. ATM I don't have SCSI around to test it, only IDE (ATA100/ATA133).

I've tested this too for .22-pre7, changing "MAX_NR_REQUESTS 1024" to "4". And now the big surprise: Still mouse stops, keyboard stops while, e.g. the above dd command, but with, for sure, very low throughput. So throughput dropping is not the problem here at all. I have very very low throughput but still pauses/stops. How is this possible? I am very confused about the code :-(

well, ext2 does not make any difference :-(

I thought trying out q->full from Chris would make any difference. I am quite sure that it must be a merge error by me, otherwise I cannot explain why q->full kills my X-windows for tons of seconds during a "make -j16 bzImage modules" I get stops of the whole system too for some seconds every 30 seconds or so. Ripped out q->full (not just disabling via elvtune -b 0) fixed at least that behaviour.

Another funny thing, not dependant on q->full, is, that VMware needs over 1 Minute to start up with a Windows 2000 in it where w/o the lowlat elevator it needs ~30 seconds or less to start up completely. VMware has reads/writes during the startup about _max_ of 500kb/s. Before it went up to 10mb/s. Now we should decide if it's either a bug in the kernel or a bug in VMware ;))

ok :) thnx. Sorry again for the delay, but I wanted to be sure about the reports so I had to test many things out first.

Hmm, I am a bit afraid that no one else noticed this yet. This reminds be back to over a year ago where I reported I/O stalls/pauses/stops with 2.4.19-pre's and no one noticed that but you after some time. A 'real' fix for that came up over one year later and some days before we had a big discussion about it with many people involved noticing it too.

Don't get me wrong Andrea and Chris :) .. but I am quite disappointed about current Linux for the Desktop. 2.4 has I/O problems, 2.6 has Scheduler problems, 2 things I cannot live with for my Desktop. Maybe Linus is right when he said, Linux may be Desktop ready in 2006.

Any suggestions what I can do to help to fix that silly behaviour? I really really want a usable 2.4 tree again (read: 2.4.22 final) :)

P.S.: I've CC'ed Nick.

ciao, Marc

Ok, there's something fundamental we're missing here, the IDE boxes I test on don't show this ;-) Can you setup a serial console and capture sysrq-t during the pause? Or better yet setup kgdb.

What kind of keyboard/mouse do you have?

I'll give you an updated q->full patch on Monday, including the __get_request_wait latency stats.

-chris

Any reason you don't use a backport of hugetlbfs like the IA64 or the RH AS3 tree?

bigpages= is a documented API that has to be used in production, so I can easily add the hugetlbfs API but I guess I've to keep this one anyways. I also would need to verify the performance of hugetlbfs before suggesting migrating to it, for example I don't want preallocation/prefaulting (IIRC hugetlbfs preallocates everything). I also like the single huge array of page pointers, that is very hardwired but optimal for those workloads.

Andrea

Most of the complaints I've gotten are about lack of support for mixed PSE and non-PSE mappings, not preallocation or performance (generally its usage doesn't involve creation/destruction cycle performance requirements, and most of the time they intend to use 100% of the memory).

It's basically too stupid and operating on too small a data set to screw up performance-wise apart from creation/destruction, which is not intended to be performant (and will never be; it blits oversized areas).

I wouldn't mind hearing of what you believe is missing, so long as it's within the constraints of what's mergeable. =(

-- wli

I tend to think the creation/destruction will be the most noticeable performance difference in practice. allocating 42G in a single block will take a bit of time ;). I'm not necessairly worse or unacceptable, but it's different. And I feel I've to retain the bigpages= API (as an API not as in implementation) anyways. Furthmore I'm unsure if hugtlbfs is relaxed like the shm-largpeage patch is, I mean, it should be possible to mmap the stuff with 4k granularty too, or stuff could break due that change of API too.

Andrea

I've just not gotten feedback about creation and destruction; I get the impression it's an uncommon operation.

The alignment etc. considerations are bits I probably can't get merged. =(

Most of the work I did was trying to get the preexisting semantics into more standard-looking API's, e.g. vfs ops and standard-ish sysv shm.

-- wli

It's uncommon of course. A 42G allocated all at once, may take a while and 48G works flawlessy at peak performance w/o 4:4. I support as much as 64G all in a single shmfs file backed by bigpages (and it won't run out of memory with a 64G box either, even with the 3:1 mapping)

so the apps will need changes and a kernel API way to know the hardware page size provided by hugetlbfs (though they could probe for it with many tries).

yes.

Andrea

The hugepage size is exported in /proc/meminfo for the time being.

I think 2.7 will see something we both like better.

-- wli

ok.

the transparency feature in the shm-largepage patch is quite nice since you could trivially put an app on the fs w/o any breakage that way (not everything has to be strictly mapped with bigpages, so it would make the code more relaxed by just changing the mountpoint). Of course a way to know for sure if a mapping is marked VM_LARGEPAGE would be needed then to be sure the app has the right pieces of vm backed with the right page size.

Andrea