ChangeSet@1.1547, 2004-12-17 23:11:00-02:00, solar@openwall.com
[PATCH] Fix booting off USB CD-ROMs (do_mounts.c)
Fix for booting off USB CD-ROMs (to do_mounts.c).
ChangeSet@1.1546, 2004-12-17 22:55:57-02:00, marcelo@logos.cnet
[PATCH] Backport v2.6 tty/ldisc locking fixes
ChangeSet@1.1545, 2004-12-17 22:17:50-02:00, akpm@osdl.org
[PATCH] If the machine is full of unmapped clean pagecache pages the kernel won't even try to reclaim inodes
> vm_vfs_scan_ratio:
> ------------------
> is what proportion of the VFS queues we will scan in one go.
> A value of 6 for vm_vfs_scan_ratio implies that 1/6th of the
> unused-inode, dentry and dquot caches will be freed during a
> normal aging round.
> Big fileservers (NFS, SMB etc.) probably want to set this
> value to 3 or 2.
>
> The default value is 6.
> =============================================================
Thanks for the info - but doesn't increasing the value of
vm_vfs_scan_ratio mean that less of the caches will be freed?
Doing a few tests (on another test file system with 2 million or so
files and 1Gb of memory) running 'find $disk -type f', with
vm_vfs_scan_ratio set to 6 (or 10), the first two column values for
xfs_inode, linvfs_icache and dentry_cache in /proc/slabinfo reach about
900000 and stay around that value, but setting vm_vfs_scan_ratio to 1,
then each value still reaches 900000, but then falls to a few thousand
and increases up to 900000 and then drop away again and repeats.
This still happens when I cat many large files (100Mb) to /dev/null at
the same time as running the find i.e. the inode caches can still reach
90% of the memory before being reclaimed (with vm_vfs_scan_ratio set to 1).
If I stop the find process when the inode caches reach about 90% of the
memory, and then start cat'ing the large files, it appears the inode
caches are never reclaimed (or longer than it takes to cat 100Gb of data
to /dev/null) - is this expected behaviour?
It seems the inode cache has priority over cached file data.
What triggers the 'normal ageing round'? Is it possible to trigger this
earlier (at a lower memory usage), or give a higher priority to cached data?
From: Andrew Morton <akpm@osdl.org>
It does. If the machine is full of unmapped clean pagecache pages the
kernel won't even try to reclaim inodes. This should help a bit:
ChangeSet@1.1544, 2004-12-17 22:02:43-02:00, hjl@lucon.org
[PATCH] backport v2.6: Fix pty race condition
http://bugme.osdl.org/show_bug.cgi?id=3894
Created an attachment (id=4277)
--> (http://bugme.osdl.org/attachment.cgi?id=4277&action=view)
A patch for kernel 2.4.29
This patch should apply to kernel 2.4.29.
ChangeSet@1.1543, 2004-12-17 21:45:58-02:00, chrisw@osdl.org
[PATCH] Backport of 2.6 fix to insert_vm_struct to make it return an error rather than BUG().
Backport of 2.6 fix to insert_vm_struct to make it return an error
rather than BUG(). This eliminates a user triggerable BUG() when user
created a large vma that overlapped with arg pages during exec (could be
triggered with a.out on i386 and x86_64 and elf on ia64).
Signed-off-by: Chris Wright <chrisw@osdl.org>
===== arch/ia64/ia32/binfmt_elf32.c 1.13 vs edited =====
ChangeSet@1.1542, 2004-12-17 16:30:45-02:00, geert@linux-m68k.org
[PATCH] m68k: fix incorrect config comment in check_bugs()
M68k: Fix incorrect config comment in check_bugs()
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
ChangeSet@1.1541, 2004-12-16 16:26:55-02:00, marcelo@logos.cnet
Solar Designer: Fix do_follow_link() comment
ChangeSet@1.1540, 2004-12-16 16:06:31-02:00, chrisw@osdl.org
[PATCH] a.out: error check on set_brk
It's possible for do_brk() to fail during set_brk() when exec'ing and
a.out. This was noted with Florian's a.out binary and overcommit set to
0.
Capture this error and terminate properly.
Signed-off-by: Chris Wright <chrisw@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
ChangeSet@1.1539, 2004-12-16 06:20:26-02:00, marcelo@logos.cnet
Changed EXTRAVERSION to -pre2
TAG: v2.4.29-pre2