linux-kernel - Re: [RFC PATCH 10/11] Drivers: hv: vmbus: Introduce the CHANNELMSG

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: <20200403145533.GA26675@andrea>
Date:   Fri, 3 Apr 2020 16:55:53 +0200
From:   Andrea Parri <parri.andrea@...il.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>
Cc:     Dexuan Cui <decui@...rosoft.com>,
        Michael Kelley <mikelley@...rosoft.com>,
        "K . Y . Srinivasan" <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Wei Liu <wei.liu@...nel.org>, linux-hyperv@...r.kernel.org,
        linux-kernel@...r.kernel.org, Boqun Feng <boqun.feng@...il.com>
Subject: Re: [RFC PATCH 10/11] Drivers: hv: vmbus: Introduce the
 CHANNELMSG_MODIFYCHANNEL message type

> > I can only think of a 'lazy' approach to setting channel CPU affinity:
> > we actually re-assign it to the target CPU when we receive first
> > interrupt there - but it's not very different from re-assigning it there
> > but still handling interrupts on the old CPU like you do.
> 
> Interesting!  I'm wondering whether it'd make sense to use a similar
> approach to (lazily) "unblock" the "old" CPUs; let me think more...

So, I spent some more time thinking about this...  AFAICT, one main
issue with this approach (besides the fact that we'd need to "save"
the "old" CPUs...) is that we might be blocking that CPU for "too
long" (depending on the channel/device usage); also, this approach
seemed to make the handling of target_cpu a bit more involved, and
this is a concern considered that (as mentioned before) we'd like to
keep the target_cpu of *all* channels in the system balanced.

I'm sticking to the approach implemented here for now: I'm planning
to send a new version of the series with minor changes soon.

Thanks,
  Andrea