linux-kernel - Re: [Patch v2] Storvsc: Select channel based on available percentage of ring buffer to write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180420085043.3a678b89@xeon-e3>
Date:   Fri, 20 Apr 2018 08:50:43 -0700
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Long Li <longli@...uxonhyperv.com>
Cc:     longli@...rosoft.com, "K . Y . Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        "James E . J . Bottomley" <JBottomley@...n.com>,
        "Martin K . Petersen" <martin.petersen@...cle.com>,
        devel@...uxdriverproject.org, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [Patch v2] Storvsc: Select channel based on available
 percentage of ring buffer to write

On Thu, 19 Apr 2018 14:54:24 -0700
Long Li <longli@...uxonhyperv.com> wrote:

> From: Long Li <longli@...rosoft.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@...rosoft.com>

Reviewed-by: Stephen Hemminger <sthemmin@...rosoft.com>