linux-kernel - Re: [RFC] [PATCH 0/3] Add group fairness to CFS

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] [day] [month] [year] [list]

Date:	Fri, 25 May 2007 13:29:36 +0530
From:	Srivatsa Vaddagiri <vatsa@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>, efault@....de,
	kernel@...ivas.org, containers@...ts.osdl.org,
	ckrm-tech@...ts.sourceforge.net, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, pwil3058@...pond.net.au,
	tingy@...umass.edu, tong.n.li@...el.com, wli@...omorphy.com,
	linux-kernel@...r.kernel.org, Balbir Singh <balbir@...ibm.com>
Subject: Re: [RFC] [PATCH 0/3] Add group fairness to CFS

On Wed, May 23, 2007 at 08:32:52PM +0200, Ingo Molnar wrote:
> > Here's an attempt to extend CFS (v13) to be fair at a group level, 
> > rather than just at task level. The patch is in a very premature state 
> > (passes simple tests, smp load balance not supported yet) at this 
> > point. I am sending it out early to know if this is a good direction 
> > to proceed.
> 
> cool patch! :-)

Thanks!

> > 1. This patch reuses CFS core to achieve fairness at group level also.
> > 
> >    To make this possible, CFS core has been abstracted to deal with 
> >    generic schedulable "entities" (tasks, users etc).
> 
> yeah, i like this alot.
> 
> The "struct sched_entity" abstraction looks very clean, and that's the 
> main thing that matters: it allows for a design that will only cost us 
> performance if group scheduling is desired.
> 
> If you could do a -v14 port and at least add minimal SMP support: i.e. 
> it shouldnt crash on SMP, but otherwise no extra load-balancing logic is 
> needed for the first cut - then i could try to pick all these core 
> changes up for -v15. (I'll let you know about any other thoughts/details 
> when i do the integration.)

Sure ..I will work on a -v14 port. I would like to target for something which:

1. doesn't break performance/functionality of existing CFS scheduler
  -if- CONFIG_FAIR_USER_SCHEDULER is disabled. This also means load
  balance should work as it works today when the config option is
  disabled.

  Do you recommend a set of tests that I need to run to ensure there
  is no regression? I know that there is a bunch of scheduler
  tests floating around on lkml ..Just need to dig to them (or if
  someone has all these tests handy on a website, I will download from
  that site!)

2. Provides fairness at group (user) level at the cost of missing load
   balance functionaility (missing until I get around to work on it that
   is).

> kernel builds dont really push scheduling micro-costs, rather try 
> something like 'hackbench.c' to measure that. (kernel builds are of 
> course one of our primary benchmarks.)

sure i will try that on my next version.

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