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: Tue, 12 Feb 2008 03:37:10 +0900 From: "KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com> To: "Andreas Dilger" <adilger@....com> Cc: "Jon Masters" <jonathan@...masters.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Marcelo Tosatti" <marcelo@...ck.org>, "Daniel Spang" <daniel.spang@...il.com>, "Rik van Riel" <riel@...hat.com>, "Andrew Morton" <akpm@...ux-foundation.org>, "Alan Cox" <alan@...rguk.ukuu.org.uk>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>, "Pavel Machek" <pavel@....cz>, "Al Boldi" <a1426z@...ab.com>, "Zan Lynx" <zlynx@....org> Subject: Re: [sample] mem_notify v6: usage example Hi Andreas, Thank you very good comment. > Having such notification handled by glibc to free up unused malloc (or > any heap allocations) would be very useful, because even if a program > does "free" there is no guarantee the memory is returned to the kernel. Yes, no guarantee. but current glibc-malloc very frequently return memory to kernel. glibc default behavior 1. over 1M memory: return memory just free(3) called. (you can change threshold by MALLOC_MMAP_MAX_ environment) 2. more lower: return memory when exist continuous 128k at heap tail. (you can change threashold by MALLOC_TRIM_THRESHOLD_ environment) if you know very memory consumption by already freed memory situation, please tell me situation detail and consumption memory size. > I think that having a generic reservation framework is too complex, but > hiding the details of /dev/mem_notify from applications is desirable. > A simple wrapper (possibly part of glibc) to return the poll fd, or set > up the signal is enough. Agreed. if large consumption situation exist, I'm behind you. Thanks! -- 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