like a very good approach, it pushes a lot of large local vars off into the helper. There is one build-time problem if DEBUG is turned on: if (args.fsbno != NULLFSBLOCK) { ap->firstblock = ap->
patch reduces xfs_page_state_convert() stack usage by 16 bytes by eliminating some local variables, and reducing the size of scope for other locals. Compile tested only. Signed-off-by:
in, David, struct kiocb is placed on stack by, for example, do_sync_write(). Eventually it contributes to xfs writeout path's stack usage, among others. This is *the* path which causes 4
t testing your patches? if you are touching the writeback or allocator path, there's a pretty high barrier to having patches excepted, and testing them before is one of them. Go and downl
for block zero access in xfs_write_iomap_allocate() The check for block zero access should be done on non-realtime inodes. Fix the logic error in xfs_write_iomap_allocate(), and simplify th
Hi David, This patch reduces xfs_bmap_btalloc() stack usage by 50 bytes by moving part of its body into a helper function. This results in some variables not taking stack space in xfs_bmap_btalloc()
Looks like a very good approach, it pushes a lot of large local vars off into the helper. There is one build-time problem if DEBUG is turned on: if (args.fsbno != NULLFSBLOCK) { ap->firstblock = ap->
You should mark the helper noinline just to prevent gcc from possibly inlining it. Even if it doesn't with your current compiler inline heuristics vary widely between compiler versions. -Andi
I think this is a good idea, although I'd rather split the function at a local boundary. The patch below (which passes xfsqa) does that by splitting out the handling of the most complicated nullfb ca
The whole STATIC thing is weird to start with.. Yes, it's kinda unexpected and at least I don't particularly liked it. But the inlining of functions with -funit-at-a-time was such a problem for the s