Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jan 2015 10:42:11 -0700
From:      Scott Long <scott4long@yahoo.com>
To:        Sibananda Sahu <sibananda.sahu@avagotech.com>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: How to send 1MB I/O size in a single I/O request without split
Message-ID:  <840B5221-A5E5-4FBC-BA2A-F44EF4036C59@yahoo.com>
In-Reply-To: <923e4c2e65d29f2f39e0aa2f6d4ab38a@mail.gmail.com>
References:  <f94a31843fde43237d9aa13bbe543ddf@mail.gmail.com> <8B56B74C-7EBC-4D1B-89AB-46DA8ED05DD5@yahoo.com> <923e4c2e65d29f2f39e0aa2f6d4ab38a@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

> On Jan 30, 2015, at 2:41 AM, Sibananda Sahu =
<sibananda.sahu@avagotech.com> wrote:
>=20
> Hey Scoot,
>=20
> Thanks very much for your reply.
>=20
>>> -          How can I get more sge count in an I/O request?
>>>=20
>=20
>> If you want to test multiple segments, I suggest leaving you system =
running
>> for a long time with multiple processes freeing and allocating memory =
so
>> that the system becomes >fragmented.  You can also modify the =
bus_dma_tag
>> in your driver to specify a maximum segment size of 4k instead of
>> (presumably in your case) something larger.  That will force >busdma =
to
>> stop merging adjacent segments.
>=20
> As you have said:
>=20
> "The busdma API will see that the allocation is contiguous and attempt =
to
> merge the contiguous segments.  This is usually desirable since few =
segments
> reduces processing overhead in the driver and the hardware."
>=20
> If I will modify the bus_dma_tag in our driver to have a max segment =
of 4K
> then what is the performance impact?
>=20

Most drivers have a for() loop that iterates through the list of =
segments from
busdma and stores them into SGE elements for the hardware to use.  =
Obviously,
fewer segments means fewer trips through this loop.  It also means a =
smaller
SGE list, which means less command data transferred over the PCI bus.  =
Though
I cannot speak for the architecture details of your hardware, often =
times the same
optimizations apply to the hardware internally.  With modern storage =
controllers
that are doing millions of i/o=E2=80=99s per second, these small =
improvements can add up.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?840B5221-A5E5-4FBC-BA2A-F44EF4036C59>