linux-kernel - Re: [00/17] Large Blocksize Support V3

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:	Thu, 26 Apr 2007 17:15:03 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Christoph Lameter <clameter@....com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, Mel Gorman <mel@...net.ie>,
	William Lee Irwin III <wli@...omorphy.com>,
	David Chinner <dgc@....com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Badari Pulavarty <pbadari@...il.com>,
	Maxim Levitsky <maximlevitsky@...il.com>
Subject: Re: [00/17] Large Blocksize Support V3

Christoph Lameter wrote:
> On Thu, 26 Apr 2007, Nick Piggin wrote:
> 
> 
>>>>I am working now and again on some code to do this, it is a big job but
>>>>I think it is the right way to do it. But it would take a long time to
>>>>get stable and supported by filesystems...
>>>
>>>Ummm... We already have a radix tree for this???? What more is needed? You
>>>just need to go through all filesystems and make them use extends.
>>
>>I'm talking about block size > page size in the buffer layer.
> 
> 
> I fail to see the point of adding another layer when you already have a 

It isn't another layer. We already have this layer.

> mapping through the radix tree. You just need to change the way the 
> filesystem looks up pages.

You didn't think any of the criticisms of higher order page cache size
were valid?


> What are the exact requirement you are trying to address?

Block size > page cache size.


> You fundamentally cannot address the large blocksize requirements with 4k 
> pages since you simply must have larger contiguous memory.
> 
> Large blocksize means that the device can do I/O on blocks of that size.
> 
> What can be done is to create some kind of fake linearity. At one level 
> the radix tree and the address space already provide that. The radix tree 
> allows you to find the next page etc. Another approach would be to create 
> a virtual address space that fakes linearity even for the processor.
> 
> Then there are ways with I/O mmus to avoid the issues again.
> 
> However, you still have not addressed the underlying problem of the device 
> not being able to do I/O to a larger block of memory.

With iommus and sg lists?

You guys have a couple of problems, firstly you need to have ia64
filesystems accessable to x86_64. And secondly you have these controllers
without enough sg entries for nice sized IOs.

I sympathise, and higher order pagecache might solve these in a way, but
I don't think it is the right way to go, mainly because of the fragmentation
issues.

Increasing PAGE_SIZE, support for block size > page cache size, and getting
io controllers matched to a 4K page size IMO would be some good ways to
solve these problems. I know they are probably harder...

-- 
SUSE Labs, Novell Inc.
-
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/