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: <20090528165710.GB4335@redhat.com>
Date:	Thu, 28 May 2009 12:57:10 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Ryo Tsuruta <ryov@...inux.co.jp>
Cc:	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org, dm-devel@...hat.com,
	jens.axboe@...cle.com, nauman@...gle.com, dpshah@...gle.com,
	lizf@...fujitsu.com, mikew@...gle.com, fchecconi@...il.com,
	paolo.valente@...more.it, fernando@....ntt.co.jp,
	s-uchida@...jp.nec.com, taka@...inux.co.jp,
	guijianfeng@...fujitsu.com, jmoyer@...hat.com,
	dhaval@...ux.vnet.ibm.com, balbir@...ux.vnet.ibm.com,
	righi.andrea@...il.com, m-ikeda@...jp.nec.com, jbaron@...hat.com,
	agk@...hat.com, snitzer@...hat.com, akpm@...ux-foundation.org,
	peterz@...radead.org
Subject: Re: [PATCH 15/20] io-controller: map async requests to appropriate
	cgroup

On Thu, May 28, 2009 at 06:27:40PM +0900, Ryo Tsuruta wrote:
> Hi Vivek,
> 
> > +#ifdef CONFIG_TRACK_ASYNC_CONTEXT
> > +	if (elv_bio_sync(bio)) {
> > +		/* sync io. Determine cgroup from submitting task context. */
> > +		cgroup = task_cgroup(current, io_subsys_id);
> > +		return cgroup;
> > +	}
> > +
> > +	/* Async io. Determine cgroup from with cgroup id stored in page */
> > +	bio_cgroup_id = get_blkio_cgroup_id(bio);
> > +
> > +	if (!bio_cgroup_id)
> > +		return NULL;
> > +
> > +	cgroup = blkio_cgroup_lookup(bio_cgroup_id);
> > +#else
> > +	cgroup = task_cgroup(current, io_subsys_id);
> > +#endif
> > +	return cgroup;
> > +}
> 
> There is a case where a kernel thread (such as device-mapper drivers)
> submits a sync IO instead of a task which originates the IO. I think
> you should always use get_blkio_cgroup_id() to determine cgroup.
> 

Hi Ryo,

Ok. Can you give some examples of drivers which are submitting reads in
different context al-together. You mentioned in the past that dm-crypt
looks like the one. How does current CFQ takes care of that. So if a 
BE prio 7 or an RT prio 0, task is submitting a READ, CFQ will not know it
and it will put that READ in the queue of the READ submitting device
mapper thread (may be BE prio 3 or 4)? 

Always determining the cgroup from bio, will make things slower at the 
same time complicated from the CFQ point of view. Right now cfq creates
and caches the queue pointer in the io context of the bio submitting task
and assumes sync requests are coming from that task/io context. Currently
there can only be one sync queue associated with one context. So if a single
thread is submitting reads (may be a worker thread) on behalf of other
processes, then we loose the io context information. In fact currently we
don't even carry ioprio and io class information in bio.

So looks like we need to carry task io context information also in bio
to be able to associate the bio to right queue at CFQ level. This makes
it bit more complicated. For the time being I will keep it in my TODO
list and handle it once other more severe problems have been taken care
of.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ