On Mon, 12 Mar 2018 14:08:34 +1100, "Tobin C. Harding" said: > removal patch that 768 was a lot of stack space. That comment did, > however say 'deep in some transfer call chain'. I don't know what a > 'transfer call chain' (the transfer bit) is but is there some heuristic > we can use to know how deep is deep? Or more to the point, is there some > heuristic we can use to know what is an acceptable amount of stack space > to use? The canonical "why we put kernel stacks on a diet" configuration: Imagine a bunch of ISCSI targets - with IPSec wrapping the connection. Arranged into a software RAID5. With LVM. With encryption on the LV. With XFS on the encrypted LV. And then the in-kernel sharing it out over NFS. With more IPSec wrapping the NFS TCP connection. Oh, and I/O interrupts, just for fun. And most of all of that has to fit their *entire* stack chain into 2 4K pages. Suddenly, that 768 bytes is taking close to 10% of *all* of the stack that all of that call chain has to share. And I see that patch is against scsi/eata.c - which means it can plausibly end up sharing that stack scenario above starting at 'software raid5'. (For bonus points, the alert reader is invited to figure out which stack each of the above actually ends up on. No, it isn't split across enough stacks that taking 768 bytes out of any of them is acceptable.. :)
Attachment:
pgpJzfG7JkAeY.pgp
Description: PGP signature
