Chris Mason <chris.mason@xxxxxxxxxx> writes: > > Huh, 912 bytes...for select, really? From poll.h: > > /* ~832 bytes of stack space used max in sys_select/sys_poll before allocating > additional memory. */ > #define MAX_STACK_ALLOC 832 > #define FRONTEND_STACK_ALLOC 256 > #define SELECT_STACK_ALLOC FRONTEND_STACK_ALLOC > #define POLL_STACK_ALLOC FRONTEND_STACK_ALLOC > #define WQUEUES_STACK_ALLOC (MAX_STACK_ALLOC - FRONTEND_STACK_ALLOC) > #define N_INLINE_POLL_ENTRIES (WQUEUES_STACK_ALLOC / sizeof(struct poll_table_entry)) > > So, select is intentionally trying to use that much stack. It should be using > GFP_NOFS if it really wants to suck down that much stack... There are lots of other call chains which use multiple KB bytes by itself, so why not give select() that measly 832 bytes? You think only file systems are allowed to use stack? :) Basically if you cannot tolerate 1K (or more likely more) of stack used before your fs is called you're toast in lots of other situations anyways. > kernel had some sort of way to dynamically allocate ram, it could try > that too. It does this for large inputs, but the whole point of the stack fast path is to avoid it for common cases when a small number of fds is only needed. It's significantly slower to go to any external allocator. -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>