search for: seqcount

...soft.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 misunderstanding something. BTW, I just occured to me that I should've probably put the TSC reading code to mshyperv.h and use it from both vDSO and read_hv_clock_tsc() -- what do you thing? [snip] -- Vitaly

...soft.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 misunderstanding something. BTW, I just occured to me that I should've probably put the TSC reading code to mshyperv.h and use it from both vDSO and read_hv_clock_tsc() -- what do you thing? [snip] -- Vitaly

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 Luto...

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 Luto...

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 sometimes from a softirq napi context, and sometimes from a fu...

...(!worker) + return; + + spin_lock_irq(&vblank->work_lock); + vblank->worker = NULL; + + list_for_each_entry_safe(work, tmp, &vblank->pending_work, node) { + drm_vblank_put(vblank->dev, vblank->pipe); + list_del(&work->node); + + if (!--work->pending) { + write_seqcount_invalidate(&work->seqcount); + wake = true; + } + } + + spin_unlock_irq(&vblank->work_lock); + + if (wake) + wake_up_all(&vblank->work_wait_queue); + kthread_destroy_worker(worker); +} + static void drm_vblank_init_release(struct drm_device *dev, void *ptr) { struct drm...

...- we could just export max_queue_pairs files and not delete files if an RX queue is disabled) (4) Reference counting - used in case someone opens a debugfs file and then removes the virtio-net device. (5) The actual mergeable rx buffer file implementation itself. For now I have added a seqcount for memory safety, but if a read-only race condition is acceptable we could elide the seqcount. FWIW, the seqcount write in receive_mergeable() should, on modern x86, translate to two non-atomic adds and two compiler barriers, so overhead is not expected to be meaningful. We can mo...

...- we could just export max_queue_pairs files and not delete files if an RX queue is disabled) (4) Reference counting - used in case someone opens a debugfs file and then removes the virtio-net device. (5) The actual mergeable rx buffer file implementation itself. For now I have added a seqcount for memory safety, but if a read-only race condition is acceptable we could elide the seqcount. FWIW, the seqcount write in receive_mergeable() should, on modern x86, translate to two non-atomic adds and two compiler barriers, so overhead is not expected to be meaningful. We can mo...

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 sometimes from a fully preemptible context and sometimes from...

...gt; max_queue_pairs files and not delete files if an RX queue is disabled) > (4) Reference counting - used in case someone opens a debugfs > file and then removes the virtio-net device. > (5) The actual mergeable rx buffer file implementation itself. For now > I have added a seqcount for memory safety, but if a read-only race > condition is acceptable we could elide the seqcount. FWIW, the > seqcount write in receive_mergeable() should, on modern x86, > translate to two non-atomic adds and two compiler barriers, so > overhead is not expected to be me...

...ister() I don't think the API should be encouraging some shortcut here.. We can't do the above pattern because the old hmm_vma API didn't allow it, which is presumably a reason why it is obsolete. I'd rather see drivers move to a consistent pattern so we can then easily hoist the seqcount lock scheme into some common mmu notifier code, as discussed. Jason

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

...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 > misunderstanding something. You can't use seqlock, but you might be able to use seqcount. Though I doubt it given the 0 check .... Thanks, tglx

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(); sample_data(); smp_rmb(); } while (...

...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...

...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...

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 g...