Strange load spikes on 2.4.19 kernel
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 20021013.000127.43007739.davem@redhat.com.suse.lists.linux.kernel
Quoted 4 lines · David S. Miller
Allocating blocks and inodes, yes that is currently single threaded on SMP. But there is no fundamental reason for that, we just haven't gotten around to threading that bit yet.
It depends on your file system. XFS and JFS do block and inode allocation fully SMP multithreaded. reiserfs/ext2/ext3 do not.
Still in 2.4 the VFS takes the big kernel lock unnecessarily for a few VFS operations (no matter if the underlying FS needs it or not). That's fixed in 2.5.
-Andi
From: Andi Kleen <[email protected]>
Date: 13 Oct 2002 09:24:32 +0200
It depends on your file system.
...
Still in 2.4 the VFS takes the big kernel lock unnecessarily
...
That's fixed in 2.5.
All true.
Quoted 4 lines · Andi Kleen
Still in 2.4 the VFS takes the big kernel lock unnecessarily for a few VFS operations (no matter if the underlying FS needs it or not). That's fixed in 2.5.
Something I was a bit surprised to notice recently: 2.5 still holds big kernel lock around the potentially very lengthy vmtruncate() - is that one still really necessary at VFS level?
Hugh
Quoted 11 lines · Hugh Dickins
Quoted 4 lines · Andi Kleen
Still in 2.4 the VFS takes the big kernel lock unnecessarily for a few VFS operations (no matter if the underlying FS needs it or not). That's fixed in 2.5.
Something I was a bit surprised to notice recently: 2.5 still holds big kernel lock around the potentially very lengthy
vmtruncate()- is that one still really necessary at VFS level?
eww.. Truncating 1G of pagecache takes 2.5 seconds on my testbox. Probably 4 seconds if that pagecache got there via write() (need to crunch on buffer_heads as well).
There's a cond_resched() after every 16th page in truncate_inode_pages(), so it won't be very visible to humans. But a multi-second holdtime is rather rude.
Certainly we don't need to hold it across truncate_inode_pages(), which is where the heavy lifting happens. Probably, we can just push it down to vmtruncate(), around the i_op->truncate() callout.
But as ever, it's not really clear what the thing is protecting.