From: David Miller <davem@davemloft.net>
To: mpatocka@redhat.com
Cc: andi@firstfloor.org, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org, jens.axboe@oracle.com
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests
Date: Tue, 15 Jul 2008 22:37:51 +0000 [thread overview]
Message-ID: <20080715.153751.71531968.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0807151830290.22181@devserv.devel.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue, 15 Jul 2008 18:32:37 -0400 (EDT)
> On Mon, 14 Jul 2008, David Miller wrote:
>
> > From: Mikulas Patocka <mpatocka@redhat.com>
> > Date: Mon, 14 Jul 2008 19:16:17 -0400 (EDT)
> >
> > > So the question is: to reduce number of requests by 12% on an outdated
> > > SCSI card, it is sensible to maintain complicated merge accounting logic
> > > in the core block layer? To me, it doesn't seem sensible.
> >
> > Rip out the code if you like, then. I really don't have time to
> > work on this myself. So if you do, by all means do whatever
> > you think is appropriate.
>
> So add signed-off line and forward it to Linus.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
I said remove code, not turn if off. I guess you didn't like
that option even though you seem heavily convinced that it buys
us essentially nothing, and I'm even starting to agree with you.
If the VMERGE code is going to stay, and it's a bug or a limitation in
the sparc64 IOMMU code, I'd rather that get fixed.
I have FUJITA's excellent analysis of the sparc64 specific IOMMU issue
in my inbox and I intend to have a look at it when I get a chance.
WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem@davemloft.net>
To: mpatocka@redhat.com
Cc: andi@firstfloor.org, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org, jens.axboe@oracle.com
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests
Date: Tue, 15 Jul 2008 15:37:51 -0700 (PDT) [thread overview]
Message-ID: <20080715.153751.71531968.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0807151830290.22181@devserv.devel.redhat.com>
From: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue, 15 Jul 2008 18:32:37 -0400 (EDT)
> On Mon, 14 Jul 2008, David Miller wrote:
>
> > From: Mikulas Patocka <mpatocka@redhat.com>
> > Date: Mon, 14 Jul 2008 19:16:17 -0400 (EDT)
> >
> > > So the question is: to reduce number of requests by 12% on an outdated
> > > SCSI card, it is sensible to maintain complicated merge accounting logic
> > > in the core block layer? To me, it doesn't seem sensible.
> >
> > Rip out the code if you like, then. I really don't have time to
> > work on this myself. So if you do, by all means do whatever
> > you think is appropriate.
>
> So add signed-off line and forward it to Linus.
>
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
I said remove code, not turn if off. I guess you didn't like
that option even though you seem heavily convinced that it buys
us essentially nothing, and I'm even starting to agree with you.
If the VMERGE code is going to stay, and it's a bug or a limitation in
the sparc64 IOMMU code, I'd rather that get fixed.
I have FUJITA's excellent analysis of the sparc64 specific IOMMU issue
in my inbox and I intend to have a look at it when I get a chance.
next prev parent reply other threads:[~2008-07-15 22:37 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-10 21:56 [SUGGESTION]: drop virtual merge accounting in I/O requests Mikulas Patocka
2008-07-10 21:56 ` Mikulas Patocka
2008-07-10 22:59 ` Julian Calaby
2008-07-10 22:59 ` Julian Calaby
2008-07-10 23:57 ` Mikulas Patocka
2008-07-10 23:57 ` Mikulas Patocka
2008-07-11 6:20 ` FUJITA Tomonori
2008-07-11 6:20 ` FUJITA Tomonori
2008-07-11 10:52 ` Mikulas Patocka
2008-07-11 10:52 ` Mikulas Patocka
2008-07-11 11:15 ` FUJITA Tomonori
2008-07-11 11:15 ` FUJITA Tomonori
2008-07-11 19:41 ` David Miller
2008-07-11 19:41 ` David Miller
2008-07-11 20:22 ` Mikulas Patocka
2008-07-11 20:22 ` Mikulas Patocka
2008-07-12 12:30 ` Andi Kleen
2008-07-12 12:30 ` Andi Kleen
2008-07-13 13:34 ` Mikulas Patocka
2008-07-13 13:34 ` Mikulas Patocka
2008-07-13 13:50 ` Andi Kleen
2008-07-13 13:50 ` Andi Kleen
2008-07-13 19:46 ` David Miller
2008-07-13 19:46 ` David Miller
2008-07-13 20:13 ` Andi Kleen
2008-07-13 20:13 ` Andi Kleen
2008-07-13 23:53 ` Mikulas Patocka
2008-07-13 23:53 ` Mikulas Patocka
2008-07-14 0:48 ` David Miller
2008-07-14 0:48 ` David Miller
2008-07-14 12:16 ` Mikulas Patocka
2008-07-14 12:16 ` Mikulas Patocka
2008-07-14 12:28 ` David Miller
2008-07-14 12:28 ` David Miller
2008-07-14 14:03 ` Mikulas Patocka
2008-07-14 14:03 ` Mikulas Patocka
2008-07-14 21:37 ` David Miller
2008-07-14 21:37 ` David Miller
2008-07-14 23:16 ` Mikulas Patocka
2008-07-14 23:16 ` Mikulas Patocka
2008-07-15 1:31 ` David Miller
2008-07-15 1:31 ` David Miller
2008-07-15 22:32 ` Mikulas Patocka
2008-07-15 22:32 ` Mikulas Patocka
2008-07-15 22:37 ` David Miller [this message]
2008-07-15 22:37 ` David Miller
2008-07-15 22:59 ` Mikulas Patocka
2008-07-15 22:59 ` Mikulas Patocka
2008-07-15 2:40 ` FUJITA Tomonori
2008-07-15 2:40 ` FUJITA Tomonori
2008-07-14 0:41 ` David Miller
2008-07-14 0:41 ` David Miller
2008-07-14 2:19 ` FUJITA Tomonori
2008-07-14 2:19 ` FUJITA Tomonori
2008-07-14 3:20 ` David Miller
2008-07-14 3:20 ` David Miller
2008-07-14 17:45 ` FUJITA Tomonori
2008-07-14 17:45 ` FUJITA Tomonori
2008-07-14 21:26 ` Mikulas Patocka
2008-07-14 21:26 ` Mikulas Patocka
2008-07-15 2:40 ` FUJITA Tomonori
2008-07-15 2:40 ` FUJITA Tomonori
2008-07-15 12:09 ` Mikulas Patocka
2008-07-15 12:09 ` Mikulas Patocka
2008-07-15 12:15 ` Andi Kleen
2008-07-15 12:15 ` Andi Kleen
2008-07-15 13:16 ` Mikulas Patocka
2008-07-15 13:16 ` Mikulas Patocka
2008-07-15 14:06 ` Andi Kleen
2008-07-15 14:06 ` Andi Kleen
2008-07-15 12:19 ` FUJITA Tomonori
2008-07-15 12:19 ` FUJITA Tomonori
2008-07-16 3:10 ` David Miller
2008-07-16 3:10 ` David Miller
2008-07-16 4:38 ` FUJITA Tomonori
2008-07-16 4:38 ` FUJITA Tomonori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080715.153751.71531968.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=andi@firstfloor.org \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.