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
| ||
|
Date: Mon, 20 Aug 2007 18:02:09 +0200 From: Bernd Schmidt <bernds_cb1@...nline.de> To: David Howells <dhowells@...hat.com> CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, "Wu, Bryan" <Bryan.Wu@...log.com> Subject: Re: [PATCH] NOMMU: Separate out VMAs David Howells wrote: > Bernd Schmidt <bernds_cb1@...nline.de> wrote: > >> In do_mmap_private, I've commented out the logic to free excess pages, as it >> fragments terribly > > I wonder if there's a good heuristic for this. The problem is that whilst > not releasing excess pages _may_ seem like a good idea, if your system is > something like a single persistent app, then it really is not. > > For instance, if such an app allocates a byte over 16MB (perhaps implicitly in > the binfmt driver), then you'd completely waste a large chunk of RAM. In the > 16MB+1 case, the wastage would be a byte less than 16MB. I think it would be good to have a mechanism to group free pages by purpose - so that if we break up a high-order page in order to allocate memory for process A, then the remaining pages remain in a special pool that the allocator will prefer to hand out only to process A. >> Also, I think you're freeing high-order pages unaligned to >> their order? > > Yeah, but some of the pages might still be in use when we want to release > them. Not following you here. Is it valid to free an order-2 page that's not aligned at order-2? >> In do_munmap, we can deal with freeing more than one vma. I've not touched >> the rb-tree logic in the shared file case, as I have no idea what it's trying >> to do given that only exact matches are allowed. > > I'd generally rather not do this. You can't use MAP_FIXED to request adjacent > regions, so why should you anticipate there would be any? Adjacent regions can happen by accident, and the uClibc malloc will try to merge free areas when they are adjacent - there's a lot of special-case code in there to prevent this on uClinux systems by essentially duplicating VMA tracking. That's something we want to avoid, because it eats performance (especially in threaded apps due to additional locking). Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists