search for: seqcounts

Stephen Hemminger <sthemmin at microsoft.com> writes: > Why not use existing seqlock's? > To be honest I don't quite understand how we could use it -- the sequence locking here is done against the page updated by the hypersior, we're not creating new structures (so I don't understand how we could use struct seqcount which we don't have) but I may be

Stephen Hemminger <sthemmin at microsoft.com> writes: > Why not use existing seqlock's? > To be honest I don't quite understand how we could use it -- the sequence locking here is done against the page updated by the hypersior, we're not creating new structures (so I don't understand how we could use struct seqcount which we don't have) but I may be

Since sequence count algorithm is done by hypervisor, better to not reuse seqcount. Still concerned that the code is racy. -----Original Message----- From: Thomas Gleixner [mailto:tglx at linutronix.de] Sent: Friday, February 10, 2017 4:28 AM To: Vitaly Kuznetsov <vkuznets at redhat.com> Cc: Stephen Hemminger <sthemmin at microsoft.com>; x86 at kernel.org; Andy Lutomirski <luto at

Since sequence count algorithm is done by hypervisor, better to not reuse seqcount. Still concerned that the code is racy. -----Original Message----- From: Thomas Gleixner [mailto:tglx at linutronix.de] Sent: Friday, February 10, 2017 4:28 AM To: Vitaly Kuznetsov <vkuznets at redhat.com> Cc: Stephen Hemminger <sthemmin at microsoft.com>; x86 at kernel.org; Andy Lutomirski <luto at

When we fill up a receive VQ, try_fill_recv currently tries to count kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that uses a seqcount. sequence counts are "lock" constructs where you need to make sure that writers are serialized. In turn, this means that we mustn't run two try_fill_recv concurrently. Which of course we don't. We do run try_fill_recv

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled

Hi Jason, Michael Sorry for the delay in response. Jason, I agree this patch ended up being larger than expected. The major implementation parts are: (1) Setup directory structure (driver/per-netdev/rx-queue directories) (2) Network device renames (optional, so debugfs dir has the right name) (3) Support resizing the # of RX queues (optional - we could just export max_queue_pairs files and

Hi Jason, Michael Sorry for the delay in response. Jason, I agree this patch ended up being larger than expected. The major implementation parts are: (1) Setup directory structure (driver/per-netdev/rx-queue directories) (2) Network device renames (optional, so debugfs dir has the right name) (3) Support resizing the # of RX queues (optional - we could just export max_queue_pairs files and

When we fill up a receive VQ, try_fill_recv currently tries to count kicks using a 64 bit stats counter. Turns out, on a 32 bit kernel that uses a seqcount. sequence counts are "lock" constructs where you need to make sure that writers are serialized. In turn, this means that we mustn't run two try_fill_recv concurrently. Which of course we don't. We do run try_fill_recv

On Fri, Jan 10, 2014 at 09:19:37PM -0800, Michael Dalton wrote: > Hi Jason, Michael > > Sorry for the delay in response. Jason, I agree this patch ended up > being larger than expected. The major implementation parts are: > (1) Setup directory structure (driver/per-netdev/rx-queue directories) > (2) Network device renames (optional, so debugfs dir has the right name) > (3)

On Wed, Jul 03, 2019 at 11:44:58AM -0700, Christoph Hellwig wrote: > Checking range->valid is trivial and has no meaningful cost, but > nicely simplifies the fastpath in typical callers. It should not be the typical caller.. > hmm_vma_range_done function, which now is a trivial wrapper around > hmm_range_unregister. > > Signed-off-by: Christoph Hellwig <hch at

On 01/07/2014 01:25 PM, Michael Dalton wrote: > Add initial support for debugfs to virtio-net. Each virtio-net network > device will have a directory under /virtio-net in debugfs. The > per-network device directory will contain one sub-directory per active, > enabled receive queue. If mergeable receive buffers are enabled, each > receive queue directory will contain a read-only file

On 01/07/2014 01:25 PM, Michael Dalton wrote: > Add initial support for debugfs to virtio-net. Each virtio-net network > device will have a directory under /virtio-net in debugfs. The > per-network device directory will contain one sub-directory per active, > enabled receive queue. If mergeable receive buffers are enabled, each > receive queue directory will contain a read-only file

On Fri, 10 Feb 2017, Vitaly Kuznetsov wrote: > Stephen Hemminger <sthemmin at microsoft.com> writes: > > > Why not use existing seqlock's? > > > > To be honest I don't quite understand how we could use it -- the > sequence locking here is done against the page updated by the > hypersior, we're not creating new structures (so I don't understand

On Fri, 10 Feb 2017, Stephen Hemminger wrote: > Since sequence count algorithm is done by hypervisor, better to not reuse seqcount. > Still concerned that the code is racy. That's a different question and can only be answered by the hypervisor folks. Dunno, whether they have barrier requirements. The seqcount stuff relies on: do { seq = READ_ONCE(s->sequence); smp_rmb();

...send v2 with some modifications to keep >>>> the discussion going. >>> >>> Migration is irrelevant. The TSC page is guest global so updates will >>> happen on some (random) host CPU and therefor you need the usual barriers >>> like we have them in our seqcounts unless an access to the sequence will >>> trap into the host, which would defeat the whole purpose of the TSC page. >>> >> >> KY Srinivasan <kys at microsoft.com> writes: >> >>> I checked with the folks on the Hyper-V side and they have confirmed t...

...send v2 with some modifications to keep >>>> the discussion going. >>> >>> Migration is irrelevant. The TSC page is guest global so updates will >>> happen on some (random) host CPU and therefor you need the usual barriers >>> like we have them in our seqcounts unless an access to the sequence will >>> trap into the host, which would defeat the whole purpose of the TSC page. >>> >> >> KY Srinivasan <kys at microsoft.com> writes: >> >>> I checked with the folks on the Hyper-V side and they have confirmed t...

Sorry, just realized - I think disabling NAPI is necessary but not sufficient. There is also the issue that refill_work() could be scheduled. If refill_work() executes, it will re-enable NAPI. We'd need to cancel the vi->refill delayed work to prevent this AFAICT, and also ensure that no other function re-schedules vi->refill or re-enables NAPI (virtnet_open/close, virtnet_set_queues,

Sorry, just realized - I think disabling NAPI is necessary but not sufficient. There is also the issue that refill_work() could be scheduled. If refill_work() executes, it will re-enable NAPI. We'd need to cancel the vi->refill delayed work to prevent this AFAICT, and also ensure that no other function re-schedules vi->refill or re-enables NAPI (virtnet_open/close, virtnet_set_queues,

...migrating between CPUs) I'd like to send v2 with some modifications to keep >> the discussion going. > > Migration is irrelevant. The TSC page is guest global so updates will > happen on some (random) host CPU and therefor you need the usual barriers > like we have them in our seqcounts unless an access to the sequence will > trap into the host, which would defeat the whole purpose of the TSC page. > KY Srinivasan <kys at microsoft.com> writes: > I checked with the folks on the Hyper-V side and they have confirmed that we need to > add memory barriers in the gu...