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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0704261059500.3263@schroedinger.engr.sgi.com>
Date:	Thu, 26 Apr 2007 11:03:01 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Christoph Hellwig <hch@...radead.org>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	David Chinner <dgc@....com>, linux-kernel@...r.kernel.org,
	Mel Gorman <mel@...net.ie>,
	William Lee Irwin III <wli@...omorphy.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

On Thu, 26 Apr 2007, Eric W. Biederman wrote:

> My most practical suggestion is to have support code so that you can
> do all of the locking (that I/O cares about) on the first page of a
> page group in the page cache.  You don't need larger physical pages to
> do that.

Virtual mappings for larger pages? Or some software simulated form? This 
all sounds like awful hacks.

> Iff we really the larger physical page size to support the hardware
> then it makes sense to go down a path of larger pages.  But it doesn't.

You are redefining the problem. We need larger physical sizes to support 
the hardware. Yes. We can dodge the issue with shim layers and hacks. It 
is obvious from the kernel sources that this is needed.

> There is also a more fundamental reasons this patch is silly.  It assumes
> that there is a trivial mapping between filesystems (the primary target
> of the page cache and blocks on disk).  Now I admit this is common but
> there is no reason to supposed it is true, and this patch appears to
> exacerbate things.

The patch does the obvious... Nothing is silly about memory being 
contigous in memory and on disk.
-
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/