From: Stephen Hemminger <stephen@networkplumber.org>
To: Long Li <longli@linuxonhyperv.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>,
linux-scsi@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>,
"James E . J . Bottomley" <JBottomley@odin.com>,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
Haiyang Zhang <haiyangz@microsoft.com>
Subject: Re: [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write
Date: Fri, 20 Apr 2018 08:50:43 -0700 [thread overview]
Message-ID: <20180420085043.3a678b89@xeon-e3> (raw)
In-Reply-To: <20180419215424.3557-1-longli@linuxonhyperv.com>
On Thu, 19 Apr 2018 14:54:24 -0700
Long Li <longli@linuxonhyperv.com> wrote:
> From: Long Li <longli@microsoft.com>
>
> This is a best effort for estimating on how busy the ring buffer is for
> that channel, based on available buffer to write in percentage. It is still
> possible that at the time of actual ring buffer write, the space may not be
> available due to other processes may be writing at the time.
>
> Selecting a channel based on how full it is can reduce the possibility that
> a ring buffer write will fail, and avoid the situation a channel is over
> busy.
>
> Now it's possible that storvsc can use a smaller ring buffer size
> (e.g. 40k bytes) to take advantage of cache locality.
>
> Changes.
> v2: Pre-allocate struct cpumask on the heap.
> Struct cpumask is a big structure (1k bytes) when CONFIG_NR_CPUS=8192 (default
> value when CONFIG_MAXSMP=y). Don't use kernel stack for it by pre-allocating
> them using kmalloc when channels are first initialized.
>
> Signed-off-by: Long Li <longli@microsoft.com>
Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com>
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Hemminger <stephen@networkplumber.org>
To: Long Li <longli@linuxonhyperv.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>,
linux-scsi@vger.kernel.org,
"Martin K . Petersen" <martin.petersen@oracle.com>,
"James E . J . Bottomley" <JBottomley@odin.com>,
linux-kernel@vger.kernel.org, devel@linuxdriverproject.org,
Haiyang Zhang <haiyangz@microsoft.com>
Subject: Re: [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write
Date: Fri, 20 Apr 2018 08:50:43 -0700 [thread overview]
Message-ID: <20180420085043.3a678b89@xeon-e3> (raw)
In-Reply-To: <20180419215424.3557-1-longli@linuxonhyperv.com>
On Thu, 19 Apr 2018 14:54:24 -0700
Long Li <longli@linuxonhyperv.com> wrote:
> From: Long Li <longli@microsoft.com>
>
> This is a best effort for estimating on how busy the ring buffer is for
> that channel, based on available buffer to write in percentage. It is still
> possible that at the time of actual ring buffer write, the space may not be
> available due to other processes may be writing at the time.
>
> Selecting a channel based on how full it is can reduce the possibility that
> a ring buffer write will fail, and avoid the situation a channel is over
> busy.
>
> Now it's possible that storvsc can use a smaller ring buffer size
> (e.g. 40k bytes) to take advantage of cache locality.
>
> Changes.
> v2: Pre-allocate struct cpumask on the heap.
> Struct cpumask is a big structure (1k bytes) when CONFIG_NR_CPUS=8192 (default
> value when CONFIG_MAXSMP=y). Don't use kernel stack for it by pre-allocating
> them using kmalloc when channels are first initialized.
>
> Signed-off-by: Long Li <longli@microsoft.com>
Reviewed-by: Stephen Hemminger <sthemmin@microsoft.com>
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2018-04-20 15:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-19 21:54 [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write Long Li
2018-04-19 21:54 ` Long Li
2018-04-20 15:50 ` Stephen Hemminger [this message]
2018-04-20 15:50 ` Stephen Hemminger
2018-04-20 19:40 ` Martin K. Petersen
2018-04-20 19:40 ` Martin K. Petersen
2018-04-22 18:53 ` Michael Kelley (EOSG)
2018-04-22 18:53 ` Michael Kelley (EOSG)
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=20180420085043.3a678b89@xeon-e3 \
--to=stephen@networkplumber.org \
--cc=JBottomley@odin.com \
--cc=devel@linuxdriverproject.org \
--cc=haiyangz@microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=longli@linuxonhyperv.com \
--cc=martin.petersen@oracle.com \
--cc=sthemmin@microsoft.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.