This may be the last update for a week (unless there's a quick bug to
fix before next morning :). I wanted to ship async-io and largepage
support now even if they're not tested well yet, in order to possibly
get feedback while I'll be away.
If you need to use it in production and you need to go completely safe
you should backout (patch -R) these three patches in this below order
(then it'll be for sure as stable as any previous -aa):
9910_shm-largepage-1.gz
9900_aio-API-x86-2
9900_aio-2.gz
But even the above cannot introduce instability unless you actively use
those features (see below how to enable largepage support). (so as worse
it could be a DoS local security problem if something oopses in aio or
similar)
However for any long term permanent installation you should at least
backout the:
9900_aio-API-x86-1
for API reasons, in case in 2.5 those syscall numbers will be assigned
to different functions. I guess the syscall numbers are basically just
assigned after latest Ben's 2.5 patch but just in case.
URL:
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19rc4aa1.gz
http://www.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19rc4aa1/
diff between 2.4.19rc3aa4 and 2.4.19rc4aa1:
Only in 2.4.19rc3aa4: 00_d_unhash-race-1
Only in 2.4.19rc3aa4: 00_mmx_xmm-init-2
Only in 2.4.19rc3aa4: 00_vm86-3
Only in 2.4.19rc3aa4: 00_vm86-drop-v86mode-dead-thread-var-1
Only in 2.4.19rc3aa4: 00_vm86-pagetablelock-1
Merged in mainline.
Only in 2.4.19rc4aa1: 00_disable-reada-1
Fix failure of bread against reada by disabling reada
(from Andrew Morton).
Only in 2.4.19rc3aa4: 00_extraversion-3
Only in 2.4.19rc4aa1: 00_extraversion-4
Only in 2.4.19rc3aa4: 9900_aio-1.gz
Only in 2.4.19rc4aa1: 9900_aio-2.gz
Merge new cancellation API from Ben, drop the POLL and READX
functionalities (apparently they were experimental). pipe callbacks
doesn't implement yet the new cancellation API, they don't overwrite
the io_event structure yet, so temporarly disabled the copy_to_user of
such structure in sys_io_cancel (so not fully compliant yet), that
would otherwise expose uninitialized kernel stack to userspace (will be
fixed ASAP).
Didn't merged the sys_getevents_abs modification, it still takes
the timeout as argument, I still prefer it for the lower overhead in
the timeout case, despite it has a larger window for going out of sync
with the timeoftheday (a window with userspace in between where context
switches cannot disabled). Waiting a final judjment for 2.5 before
making any change here.
Only in 2.4.19rc3aa4: 9900_aio-API-x86-1
Only in 2.4.19rc4aa1: 9900_aio-API-x86-2
Go in sync with latest syscall numbering in Ben's proposed patch and
dropped sys_io_wait enterely.
Only in 2.4.19rc4aa1: 9910_shm-largepage-1.gz
Merge largpage support for shared memory from Ingo Molnar.
Dropped from it all the ABI kernel changes like the unregistered
MAP_BIGPAGE 0x40 as parameter to teh mmap syscall, 0x40 can do
a completely different thing in 2.5, the original version of the patch
wasn't backwards compatible. This one is fully backwards (or better
"forward") binary compatible because it's API-less (well.. almost, you
will get -EINVAL if you attempt a MAP_PRIVATE in /dev/shm then and
stuff like that, _but_ only after enabling the support via sysctl).
Completely untested though but no need to worry until/unless you run
"echo 1 >/proc/sys/kernel/shm-use-bigpages", you also need to specify
at boot how much memory you reserve for largepages, with bigpages=1g or
similar (same memparse sintax of mem=).
After the largepage shm support is enabled all shm segments will
be attempted to be backed from largepages. largepages don't apply
to file backed mappings or anonymoys mappings, just shared memory
either from mmap("/dev/zero", MAP_SHARED), /dev/shm or shmget/shmat.
In particular the shmget API will preallocate all pages (minor note: not the
pagetables, page faults will still happen!) before returning from the
syscall (could be changed very easily with a one liner, but I guess
those db prefer the pages to be preallocated). All shm segments backed
by largepages are VM_LOCKED (unpageable to swap).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:14 EST