linux-kernel - Re: [patch 1/4] io controller: documentation

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: <20081107113209.a6011c67.kamezawa.hiroyu@jp.fujitsu.com>
Date:	Fri, 7 Nov 2008 11:32:09 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	vgoyal@...hat.com
Cc:	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org,
	virtualization@...ts.linux-foundation.org, jens.axboe@...cle.com,
	Hirokazu Takahashi <taka@...inux.co.jp>,
	Ryo Tsuruta <ryov@...inux.co.jp>,
	Andrea Righi <righi.andrea@...il.com>,
	Satoshi UCHIDA <s-uchida@...jp.nec.com>,
	Rik van Riel <riel@...hat.com>, fernando@....ntt.co.jp,
	Jeff Moyer <jmoyer@...hat.com>, menage@...gle.com,
	ngupta@...gle.com, Andrew Morton <akpm@...ux-foundation.org>,
	balbir@...ux.vnet.ibm.com
Subject: Re: [patch 1/4] io controller: documentation

On Thu, 06 Nov 2008 10:30:23 -0500
vgoyal@...hat.com wrote:
> +ISSUES
> +======
> +- IO controller can buffer the bios if suffcient tokens were not available
> +  at the time of bio submission. Once the tokens are available, these bios
> +  are dispatched to elevator/lower layers in first come first serve manner.
> +  And this has potential to break CFQ where a RT tasks should be able to
> +  dispatch the bio first or a high priority task should be able to release
> +  more bio as compared to low priority task in same cgroup.
> +
> +  Not sure how to fix it. May be we need to maintain another rb-tree and
> +  keep track of RT tasks and tasks priorities and dispatch accordingly. This
> +  is equivalent of duplicating lots of CFQ logic and not sure how would it
> +  impact AS behaviour.
> 
Why you don't isolate RT tasks into other cgroup ?
   /cgroup/bio-cgroup/group_for_usual/...usual tasks.
                     /group_for_RT/ ...RT tasks. you can use high-speed path.

How about adding RT flag to bio-cgroup and skip buffering at bio-cgroup if RT
flag is set ? I think handling an usual process and RT process in "a" cgroup
just makes the code complex.

Looking into a cpu-scheduler, which is the first module handling RT, it has
some tweaks to handle RT in the system.
 - special RT scheduler.
 - isolated RT domain
 - maximum execution time allowed to RT
 ....

Maybe handling RT in following way is usual way...(if we do something in this layer)

  - Allow RT-bio-cgroup to skip limit check.
  - But RT-bio-cgroup calculates io-throuput, execution time, statistics...
  - When RT tasks in RT-bio-cgroup does excessive I/O which starves the whole system
    too long, raise safeguard-limitter. and tell users Warning or kill it.

Hmm ?

Thanks,
-Kame

--
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/