From: Boaz Harrosh <bharrosh@panasas.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Hannes Reinecke <hare@suse.de>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Chuck Lever <chuck.lever@oracle.com>, Ben Myers <bpm@sgi.com>,
lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: [LSF/MM TOPIC][ATTEND] protection information and userspace
Date: Thu, 7 Feb 2013 14:47:46 +0200 [thread overview]
Message-ID: <5113A272.2080400@panasas.com> (raw)
In-Reply-To: <51139E26.1080406@acm.org>
On 02/07/2013 02:29 PM, Bart Van Assche wrote:
> On 02/07/13 13:08, Boaz Harrosh wrote:
>> (My addition is for support of sg_lists to bsg, in a way that makes Tomo happy
>> I know that qemu was wanting this for a while as well as the multitude of
>> user-mode servers)
>
> Do you think it would help / make sense if sg_alloc_table() would be
> modified such that it allocates the entire scatterlist table via one
> vmalloc() call instead of chaining several page-sized scatterlist tables
> ? Note: such a change is not possible without modifying
> scsi_alloc_sgtable().
>
I don't think so, no. sg_alloc_table() is used not only for direct IO
also for buffered, Now vmalloc() is terribly slow and would be a bottleneck
in today's SSD performance.
I love it that the Linux Kernel never uses vmalloc internally, and only ever
chains everything to upto PAGE_SIZE sized objects. Coming from all these
other OSs that don't, believe me, it is great great performance pain.
(TLBs are a bitch)
> Bart.
>
Thanks
Boaz
WARNING: multiple messages have this Message-ID (diff)
From: Boaz Harrosh <bharrosh@panasas.com>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Hannes Reinecke <hare@suse.de>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Chuck Lever <chuck.lever@oracle.com>, Ben Myers <bpm@sgi.com>,
<lsf-pc@lists.linux-foundation.org>,
<linux-fsdevel@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
<martin.petersen@oracle.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: [LSF/MM TOPIC][ATTEND] protection information and userspace
Date: Thu, 7 Feb 2013 14:47:46 +0200 [thread overview]
Message-ID: <5113A272.2080400@panasas.com> (raw)
In-Reply-To: <51139E26.1080406@acm.org>
On 02/07/2013 02:29 PM, Bart Van Assche wrote:
> On 02/07/13 13:08, Boaz Harrosh wrote:
>> (My addition is for support of sg_lists to bsg, in a way that makes Tomo happy
>> I know that qemu was wanting this for a while as well as the multitude of
>> user-mode servers)
>
> Do you think it would help / make sense if sg_alloc_table() would be
> modified such that it allocates the entire scatterlist table via one
> vmalloc() call instead of chaining several page-sized scatterlist tables
> ? Note: such a change is not possible without modifying
> scsi_alloc_sgtable().
>
I don't think so, no. sg_alloc_table() is used not only for direct IO
also for buffered, Now vmalloc() is terribly slow and would be a bottleneck
in today's SSD performance.
I love it that the Linux Kernel never uses vmalloc internally, and only ever
chains everything to upto PAGE_SIZE sized objects. Coming from all these
other OSs that don't, believe me, it is great great performance pain.
(TLBs are a bitch)
> Bart.
>
Thanks
Boaz
next prev parent reply other threads:[~2013-02-07 12:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 19:51 [LSF/MM TOPIC][ATTEND] protection information and userspace Ben Myers
2013-02-06 20:24 ` Darrick J. Wong
2013-02-06 20:34 ` Chuck Lever
2013-02-07 9:40 ` Joel Becker
2013-02-07 10:01 ` Darrick J. Wong
2013-02-07 11:27 ` Hannes Reinecke
2013-02-07 12:08 ` Boaz Harrosh
2013-02-07 12:08 ` Boaz Harrosh
2013-02-07 12:16 ` Boaz Harrosh
2013-02-07 12:16 ` Boaz Harrosh
2013-02-07 12:33 ` Hannes Reinecke
2013-02-07 12:54 ` Boaz Harrosh
2013-02-07 12:54 ` Boaz Harrosh
2013-02-07 12:29 ` Bart Van Assche
2013-02-07 12:47 ` Boaz Harrosh [this message]
2013-02-07 12:47 ` Boaz Harrosh
2013-02-07 16:19 ` Jeff Moyer
2013-02-07 16:19 ` Jeff Moyer
2013-02-07 17:27 ` Zach Brown
2013-02-07 17:36 ` Joel Becker
2013-02-07 21:04 ` J. Bruce Fields
2013-02-08 9:38 ` Joel Becker
2013-02-07 19:12 ` Martin K. Petersen
2013-02-08 9:36 ` Joel Becker
2013-02-07 19:09 ` Martin K. Petersen
2013-02-07 23:45 ` Darrick J. Wong
2013-02-07 23:59 ` Martin K. Petersen
2013-02-07 19:20 ` Martin K. Petersen
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=5113A272.2080400@panasas.com \
--to=bharrosh@panasas.com \
--cc=bpm@sgi.com \
--cc=bvanassche@acm.org \
--cc=chuck.lever@oracle.com \
--cc=darrick.wong@oracle.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hare@suse.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=martin.petersen@oracle.com \
/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.