Re: [PATCH 1/2] block: fix leaks associated with discard requestpayload
From: Mike Snitzer
Date: Wed Jun 30 2010 - 11:36:28 EST
On Wed, Jun 30 2010 at 10:22am -0400,
James Bottomley <James.Bottomley@xxxxxxx> wrote:
> On Tue, 2010-06-29 at 20:11 -0400, Mikulas Patocka wrote:
> > > > If the layering violation spans only scsi code, it can be eventually
> > > > fixed, but this, much worse "layering violation" that will be spanning all
> > > > block device midlayers, won't ever be fixed.
> > > >
> > > > Imagine for example --- a discard request arrivers at a dm-snapshot
> > > > device. The driver splits it into chunks, remaps each chunk to the
> > > > physical chunk, submits the requests, the elevator merges adjacent
> > > > requests and submits fewer bigger requests to the device. Now, if you had
> > > > to allocate a zeroed page each time you are splitting the request, that
> > > > would exhaust memory and burn cpu needlessly. You delete a 100MB file? ---
> > > > fine, allocate a 100MB of zeroed pages.
> > >
> > > This is a straw man: You've tried to portray a position I've never
> > > taken as mine then attack it ... with what is effectively another bogus
> > > argument.
> > >
> > > It's not an either/or choice.
> > It is either/or choice. If the interface isn't fixed NOW, the existing
> > flawed zeroed-page-allocation interface gets into RHEL
> That's a false dichotomy. You might see an either apply this hack now
> or support the interface choice with RHEL, but upstream has the option
> to fix stuff correctly. RHEL has never needed my blessing to apply
> random crap to their kernel before ... why is this patch any different?
> > and I and others will have to support it for 7 years.
> It's called a business model ... I believe it's what they pay you for.
> > > I've asked the relevant parties to
> > > combine the approaches and see if a REQ_TYPE_FS path that does the
> > > allocations in the appropriate place, likely the ULD, produces a good
> > > design.
> > OK, but before you do this research, fix the interface.
> So even in the RHEL world, I think you'd find that analysing the problem
> *before* comping up with a fix is a good way of doing things.
> > > > So I say --- let there be a layering violation in the scsi code, but don't
> > > > put this problem with a page allocation to all the other bio midlayer
> > > > developers.
> > >
> > > Thanks for explaining that you have nothing to contribute, I'll make
> > > sure you're not on my list of relevant parties.
> > You misunderstand what I meant. You admit that there are design problems
> > in SCSI.
> No I didn't.
> And the rest of this rubbish is based on that false premise. It might
> help you to take off your SCSI antipathy and see this as a system
> problem: it actually originates in block and spills out from there.
> Thus it requires a system solution.
As fun as it is for the others monitoring these lists to see redhat.com
vs suse.de banter I think framing this discussion like you (and Mikulas)
continue to do is a complete distraction.
I tried to elevate (and defuse) the discussion yesterday. But simply
put: patches speak volumes. I look forward to working with Tomo, hch
and anyone else who has something to contribute that moves us toward a
real fix for discards.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/