Messages in this thread | | | Date | Tue, 22 Apr 2008 11:28:19 +1000 | From | David Chinner <> | Subject | Re: x86: 4kstacks default |
| |
On Mon, Apr 21, 2008 at 09:51:02PM +0200, Denys Vlasenko wrote: > On Monday 21 April 2008 15:29, Eric Sandeen wrote: > > > Some number has to be picked. Why fitting in 4k is "bad" and fitting > > > in 8k is "not bad"? > > > > > > Because well-written code in several subsystems, used in combination in > > common configurations, does not always fit, that is why. > > > > Show me the "bug" in an nfs+xfs+md+scsi writeback stack oops > > Why nfs+xfs+md+ide works?
Luck?
With 4k stacks, you really don't need NFS at all - you just have enter memory reclaim at the wrong time (i.e. when something else was already consuming 2/3rds of the 4k stack).
> Does scsi intrinsically require more stack than ide?
<shrug>
> Why xfs code is said to be 5 timed bigged than e.g. reiserfs? > Does it have to be that big?
If we cut the bulkstat code out, the handle interface, the preallocation, the journalled quota, the delayed allocation, all the runtime validation, the shutdown code, the debug code, the tracing code, etc, then we might get down to the same size reiser....
> Does it really have to eat lots of stack?
Writeback is done under ENOMEM pressure, and XFS can't provide the guarantees mempools need to work. That leaves the stack as the only place we can put the things we need. e.g. the args structures that tell the allocator what to do and retain state between subsequent low level allocation calls use ~250 bytes of stack just by themselves....
We've already chopped off the low hanging fruit, added noinline to every function definition to prevent compiler heuristics from blowing out stack usage by 25% and reduced use of temporary variables as much as possible. There's very little fat left to trim, and still we can't reliably fit in 4k stacks.
Patches are welcome - I'd be over the moon if any of the known 4k stack advocates sent a stack reduction patch for XFS, but it seems that actually trying to fix the problems is much harder than resending a one line patch every few months....
Cheers,
Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group
| |