| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <4A4256A6.7070707@redhat.com> Date: Wed, 24 Jun 2009 11:39:02 -0500 From: Eric Sandeen <sandeen@...hat.com> To: Theodore Tso <tytso@....edu> CC: linux-ext4@...r.kernel.org Subject: Re: Need to potentially watch stack usage for ext4 and AIO... Eric Sandeen wrote: > Theodore Tso wrote: ... >> I can see some things we can do to optimize stack usage; for example, >> struct ext4_allocation_request is allocated on the stack, and the >> structure was laid out without any regard to space wastage caused by >> alignment requirements. That won't help on x86 at all, but it will >> help substantially on x86_64 (since x86_64 requires that 8 byte >> variables must be 8-byte aligned, where as x86_64 only requires 4 byte >> alignment, even for unsigned long long's). But it's going have to be >> a whole series of incremental improvements; I don't see any magic >> bullet solution to our stack usage. > > XFS forces gcc to not inline any static function; it's extreme, but > maybe it'd help here too. Giving a blanket noinline treatment to mballoc.c yields some significant stack savings: -ext4_mb_free_blocks 200 +ext4_mb_free_blocks 184 -ext4_mb_init_cache 232 +ext4_mb_init_cache 136 -ext4_mb_regular_allocator 232 +ext4_mb_regular_allocator 104 -ext4_mb_new_blocks 104 (drops below 100 bytes) -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists