[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0709111644240.29413@schroedinger.engr.sgi.com>
Date: Tue, 11 Sep 2007 17:00:22 -0700 (PDT)
From: Christoph Lameter <clameter@....com>
To: Nick Piggin <nickpiggin@...oo.com.au>
cc: Mel Gorman <mel@...net.ie>, andrea@...e.de,
torvalds@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, Christoph Hellwig <hch@....de>,
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>,
Fengguang Wu <fengguang.wu@...il.com>,
swin wang <wangswin@...il.com>, totty.lu@...il.com,
hugh@...itas.com, joern@...ybastard.org
Subject: Re: [00/41] Large Blocksize Support V7 (adds memmap support)
On Tue, 11 Sep 2007, Nick Piggin wrote:
> > Well its seems that we have different interpretations of what was agreed
> > on. My understanding was that the large blocksize patchset was okay
> > provided that I supply an acceptable mmap implementation and put a
> > warning in.
>
> Yes. I think we differ on our interpretations of "okay". In my interpretation,
> it is not OK to use this patch as a way to solve VM or FS or IO scalability
> issues, especially not while the alternative approaches that do _not_ have
> these problems have not been adequately compared or argued against.
We never talked about not being able to solve scalability issues with this
patchset. The alternate approaches were discussed at the VM MiniSummit and
at the VM/FS meeting. You organized the VM/FS summit. I know you were
there and were arguing for your approach. That was not sufficient?
> > Well even without slab targeted reclaim: Mel's antifrag will sort the
> > dentries into separate blocks of memory and so isolate the issue.
>
> So even after all this time you do not understand what the fundamental
> problem is with anti-frag and yet you are happy to waste both our time
> in endless flamewars telling me how wrong I am about it.
We obviously have discussed this before and the only point of asking this
question by you seems to be to have me repeat the whole line argument
again?
> Forgive me if I'm starting to be rude, Christoph. This is really irritating.
Sorry but I have had too much exposure to philosophy. Talk about absolutes
like guarantees (that do not exist even for order 0 allocs) and unlikely memory
fragmentation scenarios to show that something does not work seems to
be getting into some metaphysical realm where there is no data anymore
to draw any firm conclusions.
Software reliability is inherent probabilistic otherwise we would not have
things like CRC sums and SHA1 algorithms. Its just a matter of reducing
the failure rate sufficiently. The failure rate for lower order
allocations (0-3) seems to have been significantly reduced in 2.6.23
through lumpy reclaim.
If antifrag measures are not successful (likely for 2M allocs) then other
methods (like the large page pools that you skipped when reading my post)
will need to be used.
-
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