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-next>] [day] [month] [year] [list]
Date:	Sat, 22 Jan 2011 01:17:19 +0000
From:	Jens Axboe <jaxboe@...ionio.com>
To:	jaxboe@...ionio.com, linux-kernel@...r.kernel.org
Cc:	hch@...radead.org
Subject: [PATCH 0/10] On-stack explicit block queue plugging

Hi,

This is something that I have been sitting on for a while and
I finally got a bit of time to bring it up to date and at least
ensure that basic functionality was there.

Currently we use what I call implicit IO plugging for block devices.
This means that the target block device queue may or may not be
"plugged" when someone submits IO. The IO submitter has to
ensure that the IO is sent off by calling a function to submit
it. This ugliness propagates through to the vm, which needs a
->sync_page() hook to ensure that things are submitted if someone
ends up waiting on a page.

Additionally, queue plugging ends up being a burden on the
queue lock (which is already heavily contended in some cases).
By moving to an explicit plugging scheme we make the API nicer,
get rid of the ->sync_page() vm hack, and allow IO to be queued
up in an on-stack structure and submitted in batches to the
block device queue.

Right now only submission of mergeable IO is lockless, the next
step is ensuring that rq allocation can be less queue lock
intensive and get some benefits there as well. There's an
unrelated batching change in this series as well that doesn't
really belong that's the start of that.

The patch boots and runs on my laptop, but apart from that I make
no guarantees as to the state of it. Particularly the md and dm
changes are quite invasive and need both careful review (and then,
I'm sure, bug fixing) and testing.

Patches are against 2.6.38-rc1 and can also be found in the block
git tree, in the for-2.6.39/stack-plug branch.

I'm traveling, so I'll tend to replies/comments/reviews/bugs on
this patch series when I get back early next week.

-- 
Jens Axboe

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