linux-kernel - Re: [PATCH 15/20] blkio: Take care of preemptions across groups

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: <20091104192725.GM2870@redhat.com>
Date:	Wed, 4 Nov 2009 14:27:25 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Jeff Moyer <jmoyer@...hat.com>
Cc:	linux-kernel@...r.kernel.org, jens.axboe@...cle.com,
	nauman@...gle.com, dpshah@...gle.com, lizf@...fujitsu.com,
	ryov@...inux.co.jp, fernando@....ntt.co.jp, s-uchida@...jp.nec.com,
	taka@...inux.co.jp, guijianfeng@...fujitsu.com,
	balbir@...ux.vnet.ibm.com, righi.andrea@...il.com,
	m-ikeda@...jp.nec.com, akpm@...ux-foundation.org, riel@...hat.com,
	kamezawa.hiroyu@...fujitsu.com
Subject: Re: [PATCH 15/20] blkio: Take care of preemptions across groups

On Wed, Nov 04, 2009 at 02:00:33PM -0500, Jeff Moyer wrote:
> Vivek Goyal <vgoyal@...hat.com> writes:
> 
> > +static bool cfq_should_preempt_group(struct cfq_data *cfqd,
> > +		struct cfq_queue *cfqq, struct cfq_queue *new_cfqq)
> > +{
> > +	struct cfq_entity *cfqe = &cfqq->entity;
> > +	struct cfq_entity *new_cfqe = &new_cfqq->entity;
> > +
> > +	if (cfqq_to_cfqg(cfqq) != &cfqd->root_group)
> > +		cfqe = parent_entity(&cfqq->entity);
> > +
> > +	if (cfqq_to_cfqg(new_cfqq) != &cfqd->root_group)
> > +		new_cfqe = parent_entity(&new_cfqq->entity);
> > +
> > +	/*
> > +	 * Allow an RT request to pre-empt an ongoing non-RT cfqq timeslice.
> > +	 */
> > +
> > +	if (new_cfqe->ioprio_class == IOPRIO_CLASS_RT
> > +	    && cfqe->ioprio_class != IOPRIO_CLASS_RT)
> > +		return true;
> > +	/*
> > +	 * Allow an BE request to pre-empt an ongoing IDLE clas timeslice.
> > +	 */
> > +
> > +	if (new_cfqe->ioprio_class == IOPRIO_CLASS_BE
> > +	    && cfqe->ioprio_class == IOPRIO_CLASS_IDLE)
> > +		return true;
> > +
> > +	return false;
> > +}
> 
> What was the motivation for this?  It seems like this would really break
> isolation.  What if one group has all RT priority tasks, will it starve
> out the other groups?
> 

It will not as we traverse up the hierarchy and look for the ioprio class
of the group entity.

So if you got following configuration where G1 and G2 are two groups. G1
is prio class RT and G2 is prio class BE, then any queue in G1 will
preempt any queue in G2 as at highest level, G1 and G2 are different class
altogether.

			root
			/  \
		       G1  G2

Normal cfqq preemption checks will not catch this. So if G2 has some BE
cfqq running, and some BE queue gets backlogged in G1, this new queue wil
not preempt the queue in G2 and it should have.

That's why preemption checks at group level.

Secondly if G1 and G2 are of ioprioclass BE and all the jobs in G1 are of
RT nature, they will not preempt the queues in G2, hence providing
isolation.

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