linux-kernel - Re: [PATCH 0/8][for -mm] mem

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 18 Apr 2008 19:07:49 +0900
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	"Tom May" <tom@...may.com>
Cc:	kosaki.motohiro@...fujitsu.com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8][for -mm] mem_notify v6

> madvise can be replaced with munmap and the same behavior occurs.
> 
> --- test.c.orig 2008-04-17 11:41:47.000000000 -0700
> +++ test.c 2008-04-17 11:44:04.000000000 -0700
> @@ -127,7 +127,7 @@
>     /* Release FREE_CHUNK pages. */
> 
>     for (i = 0; i < FREE_CHUNK; i++) {
> -       int r = madvise(p + page*PAGESIZE, PAGESIZE, MADV_DONTNEED);
> +       int r = munmap(p + page*PAGESIZE, PAGESIZE);
>         if (r == -1) {
>             perror("madvise");
>             exit(1);
> 
> Here's what I'm seeing on my system.  This is with munmap, but I see
> the same thing with madvise.  First, /proc/meminfo on my system before
> running the test:

Oh sorry my bad!
I investigated again and found 2 problem in your test program.

1. text segment isn't locked.

   if strong memory pressure happned, kernel may drop program text region.
   then your test program suddenly slow down.

   please use mlockall(MCL_CURRENT) before large buffer allocation.

2. repeat open/close to /proc/meminfo.

   in the fact, open(2) system call use a bit memory.
   if call open(2) in strong memory pressure, doesn't return until
   memory freed enough.
   thus, it cause slow down your program sometimes.

attached changed test program :)
it works well on my test environment.

> If it's possible to get a notification when MemFree + Cached + Mapped
> (I'm not sure whether this is the right formula) falls below some
> threshold, so that the program has time to find memory to discard
> before the system runs out, that would prevent the oom -- as long as
> the application(s) can ensure that there is not too much memory
> allocated while it is looking for memory to free.   But at least the
> threshold would give it a reasonable amount of time to handle the
> notification.

your proposal is interesting.
but I hope try to my attached test program at first.

Download attachment "tom.c" of type "application/octet-stream" (3604 bytes)