All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests
Date: Sun, 13 Jul 2008 13:50:55 +0000	[thread overview]
Message-ID: <487A083F.9010301@firstfloor.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0807130933120.24489@devserv.devel.redhat.com>

Mikulas Patocka wrote:
>> Mikulas Patocka <mpatocka@redhat.com> writes:
>>
>>> I'm getting crashes with InitIO A100u2w controller on Sparc64 (I had
>>> to fix the endianity issues in the driver, but that's unrelated).
>>
>> x86-64 (and powerpc) solved this a long time ago by only doing
>> opportunistic merging: as in don't announce to the block layer
>> that you can merge, but try to merge anyways. This way SG lists
>> are not necessarily filled completely, but it's still better
>> than overflowing them in some rare cases.
>>
>> -Andi
> 
> There's option "biomerge" that enables that feature. I'm wondering, if
> there's some situation when it should be used.

It would only help if your SG hardware is slower at processing merges
than the IOMMU.

We found some long ago that was (old MPT Fusion) that gained
a few percent on some benchmarks, but that might be quite different
depending on the particular IO controller and chipset.

Also biomerge was used for the AMD K8 GART "IOMMU" which is
relatively slow, the situation on more modern x86 IOMMUs might be
different. Also the GART IOMMU is small and fragmentation is more
likely.

The situation on the more modern real x86 IOMMU (like in newer Intel or IBM
chipsets) might be also different.

Still I would expect that modern IO controllers are typically fast
enough at processing SG lists that it shouldn't matter much.

-Andi

WARNING: multiple messages have this Message-ID (diff)
From: Andi Kleen <andi@firstfloor.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jens Axboe <jens.axboe@oracle.com>
Subject: Re: [SUGGESTION]: drop virtual merge accounting in I/O requests
Date: Sun, 13 Jul 2008 15:50:55 +0200	[thread overview]
Message-ID: <487A083F.9010301@firstfloor.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0807130933120.24489@devserv.devel.redhat.com>

Mikulas Patocka wrote:
>> Mikulas Patocka <mpatocka@redhat.com> writes:
>>
>>> I'm getting crashes with InitIO A100u2w controller on Sparc64 (I had
>>> to fix the endianity issues in the driver, but that's unrelated).
>>
>> x86-64 (and powerpc) solved this a long time ago by only doing
>> opportunistic merging: as in don't announce to the block layer
>> that you can merge, but try to merge anyways. This way SG lists
>> are not necessarily filled completely, but it's still better
>> than overflowing them in some rare cases.
>>
>> -Andi
> 
> There's option "biomerge" that enables that feature. I'm wondering, if
> there's some situation when it should be used.

It would only help if your SG hardware is slower at processing merges
than the IOMMU.

We found some long ago that was (old MPT Fusion) that gained
a few percent on some benchmarks, but that might be quite different
depending on the particular IO controller and chipset.

Also biomerge was used for the AMD K8 GART "IOMMU" which is
relatively slow, the situation on more modern x86 IOMMUs might be
different. Also the GART IOMMU is small and fragmentation is more
likely.

The situation on the more modern real x86 IOMMU (like in newer Intel or IBM
chipsets) might be also different.

Still I would expect that modern IO controllers are typically fast
enough at processing SG lists that it shouldn't matter much.

-Andi

  reply	other threads:[~2008-07-13 13:50 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 [this message]
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
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=487A083F.9010301@firstfloor.org \
    --to=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.