linux-kernel - Re: [tip:sched/numa] sched/numa: Introduce sys_numa

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 May 2012 11:48:45 -0400
From:	Rik van Riel <riel@...hat.com>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC:	mingo@...nel.org, hpa@...or.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, pjt@...gle.com, cl@...ux.com,
	bharata.rao@...il.com, akpm@...ux-foundation.org,
	Lee.Schermerhorn@...com, aarcange@...hat.com, danms@...ibm.com,
	suresh.b.siddha@...el.com, tglx@...utronix.de,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:sched/numa] sched/numa: Introduce sys_numa_{t,m}bind()

On 05/18/2012 11:35 AM, Peter Zijlstra wrote:
> On Fri, 2012-05-18 at 11:14 -0400, Rik van Riel wrote:

>> While this may work well for programs written in languages
>> with pointers, and for virtual machines, I do not see how
>> eg. a JVM could provide useful hints to the kernel, because
>> the Java program running on top has no idea about the
>> memory addresses of its objects, and the Java language has
>> no way to hint which thread will be the predominant user
>> of an object.
>
> This is one of the many reasons why you'll never see me use Java or any
> other 'managed' language.

You are hardly a typical user, though :)

Whether we like it or not, managed runtimes are here,
and people are using them in droves.

I believe that the kernel should be able to handle
NUMA placement for such uses.

>> I like your code for handling smaller processes in NUMA
>> systems, but we do need to have a serious discussion on
>> how to handle processes that do not fit in one node.
>>
>> The more I think about it, the more Andrea's code looks
>> like it might be the more flexible way forward.
>
> I still have serious concerns about his approach; it very much assumes
> there's a temporal page<->thread relation to exploit. This might not at
> all be true for some programs (including JVM) that have hardly any data
> separation and just point chase their way around the entire object set.

Neither his approach or your approach will be able to
help these workloads. I do not see how that should be
counted against Andrea's approach, though, since it
does seem to be useful for sane workloads.

> I've also yet to see a coherent patch-set from Andrea with coherent
> changelogs and comments (this very much precludes PDFs of any kind).
>
> And you know I detest the way he cobbled his way around the scheduler
> instead of integrating it properly. And I'll very much not accept
> anything like the spaghetti code anywhere near the scheduler I have to
> maintain. (I recently looked at the THP code and if that's the standard
> I'm not having it).
>
> That said, I'll leave the door open and will consider something like his
> scanning stuff as an optional add on on-top of this.

No argument there. Your scheduler integration is nicer,
and Andrea's code could stand some documentation.

> I very much believe in doing the simple thing first, and this is that,

Leave out your syscalls (which might not be useful for
managed runtimes), and you actually have the simple
thing :)

I am all in favor of simplicity, and doing one thing
at a time.

-- 
All rights reversed
--
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/