linux-kernel - Re: [PATCH 2/2] Customize sched domain via cpuset

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]

Message-ID: <47F346A8.5000801@jp.fujitsu.com>
Date:	Wed, 02 Apr 2008 17:41:12 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Paul Jackson <pj@....com>
Subject: Re: [PATCH 2/2] Customize sched domain via cpuset

Peter Zijlstra wrote:
> On Tue, 2008-04-01 at 20:27 +0900, Hidetoshi Seto wrote:
>> The implementation is here.
>>
>>  - Add 2 new cpuset files:
>>      sched_wake_idle_far
>>      sched_balance_newidle_far
>>
>>  - Modify partition_sched_domains() and build_sched_domains()
>>    to take flags parameter passed from cpuset.
>>
>>  - Fill newidle_idx for node domains which currently unused but
>>    might be required for sched_balance_newidle_far.
> 
> Just to be clear; the same effect can be had by poking into:
> 
>  /proc/sys/kernel/sched_domain/$cpu/$domain/flags
> 
> but this interface you now propose gives a more stable interface in that
> you'd have to re-do your setting after every cpuset change (admittedly
> those are rare, but I see how it could be a nuisance).

And the sysctl entry "sched_domain" is not available unless SCHED_DEBUG.

So it is common sense that this sysctl is not open to public yet,
and that the expected users are scheduler developers, Ingo and friends.

> Or do you actually add something that wasn't available through the
> initial domain interface?

At this time I have no idea, but it would be possible if there are
something unreasonable on global system but acceptable on a part.

In other words, we can invent other sched_* families which has special
effect that "default scheduler" never have.

Thanks,
H.Seto
--
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/