linux-kernel - Re: [RFC PATCH 0/7] evacuate struct page from the block layer

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]

Date:	Sun, 22 Mar 2015 18:46:15 +0200
From:	Boaz Harrosh <boaz@...xistor.com>
To:	Christoph Hellwig <hch@...radead.org>,
	Matthew Wilcox <willy@...ux.intel.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	axboe@...nel.dk, riel@...hat.com, linux-nvdimm@...1.01.org,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	linux-raid@...r.kernel.org, mgorman@...e.de,
	linux-fsdevel@...r.kernel.org
Subject: Re: [RFC PATCH 0/7] evacuate struct page from the block layer

On 03/19/2015 08:17 PM, Christoph Hellwig wrote:
<>
> 
> In addition to the options there's also a time line.  At least for the
> short term where we want to get something going 1a seems like the
> absolutely be option.  It works perfectly fine for the lots of small
> capacity dram-like nvdimms, and it works funtionally fine for the
> special huge ones, although the resource use for it is highly annoying.
> If it turns out to be too annoying we can also offer a no I/O possible
> option for them in the short run.
> 

Finally some voice in the dessert.

> In the long run option 2) sounds like a good plan to me, but not as a
> parallel I/O path, but as the main one.  Doing so will in fact give us
> options to experiment with 3).  Given that we're moving towards an
> increasinly huge page using world replacing the good old struct page
> with something extent-like and/or temporary might be needed for dram
> as well in the future.

Why ? why not just make page mean page_size(page) and mostly even that
is not needed.

Any changes to bio will only solve bio. And will push the problem to
the next subsystem.

Fix the PAGE_SIZE problem and you fixed it for all subsystems, not only
bio. And I believe it is the smaller change by far.

Because in most places PAGE_SIZE just means MIN_PAGE_SIZE when we try
calculate some array sizes for storage of a given "io-length", this
is surly 4k, but then when the actual run time is preformed we usually
have a length specifier like bv_len. (And the few places that do not are
easy to fix I believe)

Thanks
Boaz

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