linux-kernel - RE: [PATCH -v2 -mm] add extra free kbytes tunable

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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 11 Oct 2011 15:20:14 -0400
From:	Satoru Moriya <satoru.moriya@....com>
To:	David Rientjes <rientjes@...gle.com>,
	Rik van Riel <riel@...hat.com>
CC:	Randy Dunlap <rdunlap@...otime.net>,
	Satoru Moriya <smoriya@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"lwoodman@...hat.com" <lwoodman@...hat.com>,
	Seiji Aguchi <saguchi@...hat.com>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"hughd@...gle.com" <hughd@...gle.com>,
	"hannes@...xchg.org" <hannes@...xchg.org>
Subject: RE: [PATCH -v2 -mm] add extra free kbytes tunable

On 10/07/2011 11:08 PM, David Rientjes wrote:
> On Thu, 1 Sep 2011, Rik van Riel wrote:
>
> I also
> think that it will cause regressions on other cpu intensive workloads 
> that don't require this extra freed memory because it works as a 
> global heuristic and is not tied to any specific application.

It's yes and no. It may cause regressions on the workloads due to
less amount of available memory. But it may improve the workloads'
performance because they can avoid direct reclaim due to extra
free memory.

Of course if one doesn't need extra free memory, one can turn it
off. I think we can add this feature to cgroup if we want to set
it for any specific process or process group. (Before that we
need to implement min_free_kbytes for cgroup and the implementation
of extra free kbytes strongly depends on it.)

> I think it would be far better to reclaim beyond above the high 
> watermark if the types of workloads that need this tunable can be 
> somehow detected (the worst case scenario is being a prctl() that does 
> synchronous reclaim above the watermark so admins can identify these 
> workloads), or be able to mark allocations within the kernel as 
> potentially coming in large bursts where allocation is problematic.

It may work. But isn't it difficult and/or complex to decide
how much memory we should reclaim beyond high watermark
automatically?

I believe that extra free kbytes is far simpler than them.

Regards,
Satoru
--
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/