similar to: [PATCH v15 23/26] sched: early boot clock

Pavel Tatashin wrote on Thu, Jan 03, 2019: > Could you please send the config file and qemu arguments that were > used to reproduce this problem. Running qemu by hand, nothing fancy e.g. this works: # qemu-system-x86_64 -m 1G -smp 4 -drive file=/root/kvm-wrapper/disks/f2.img,if=virtio -serial mon:stdio --enable-kvm -cpu Haswell -device virtio-rng-pci -nographic (used a specific cpu just

The time_init_hook in paravirt-ops no longer functions in the correct manner after the integration of the hrtimers code. The problem is that now the call path for time initialization is: time_init : late_time_init = hpet_time_init; late_time_init -> hpet_time_init: setup_pit_timer (BAD) do_time_init --> (via paravirt.h) time_init_hook --> (via

The time_init_hook in paravirt-ops no longer functions in the correct manner after the integration of the hrtimers code. The problem is that now the call path for time initialization is: time_init : late_time_init = hpet_time_init; late_time_init -> hpet_time_init: setup_pit_timer (BAD) do_time_init --> (via paravirt.h) time_init_hook --> (via

* Pavel Tatashin <pasha.tatashin at oracle.com> wrote: > Juergen Gross noticed that commit > f7f99100d8d ("mm: stop zeroing memory during allocation in vmemmap") > broke XEN PV domains when deferred struct page initialization is enabled. > > This is because the xen's PagePinned() flag is getting erased from struct > pages when they are initialized later in

On 16/03/15 13:16, Peter Zijlstra wrote: > > I feel that if someone were to do a Xen patch we can go ahead and merge this > stuff (finally!). This seems work for me, but I've not got time to give it a more thorough testing. You can fold this into your series. There doesn't seem to be a way to disable QUEUE_SPINLOCKS when supported by the arch, is this intentional? If so, the

On Mon, Mar 16, 2015 at 02:16:13PM +0100, Peter Zijlstra wrote: > Hi Waiman, > > As promised; here is the paravirt stuff I did during the trip to BOS last week. > > All the !paravirt patches are more or less the same as before (the only real > change is the copyright lines in the first patch). > > The paravirt stuff is 'simple' and KVM only -- the Xen code was a

On Thu, Mar 26, 2015 at 09:21:53PM +0100, Peter Zijlstra wrote: > On Wed, Mar 25, 2015 at 03:47:39PM -0400, Konrad Rzeszutek Wilk wrote: > > Ah nice. That could be spun out as a seperate patch to optimize the existing > > ticket locks I presume. > > Yes I suppose we can do something similar for the ticket and patch in > the right increment. We'd need to restructure the

On Mon, Mar 30, 2015 at 12:25:12PM -0400, Waiman Long wrote: > I did it differently in my PV portion of the qspinlock patch. Instead of > just waking up the CPU, the new lock holder will check if the new queue head > has been halted. If so, it will set the slowpath flag for the halted queue > head in the lock so as to wake it up at unlock time. This should eliminate > your concern

On 16/03/15 13:16, Peter Zijlstra wrote: > > I feel that if someone were to do a Xen patch we can go ahead and merge this > stuff (finally!). This seems work for me, but I've not got time to give it a more thorough testing. You can fold this into your series. There doesn't seem to be a way to disable QUEUE_SPINLOCKS when supported by the arch, is this intentional? If so, the

On Mon, Mar 16, 2015 at 02:16:13PM +0100, Peter Zijlstra wrote: > Hi Waiman, > > As promised; here is the paravirt stuff I did during the trip to BOS last week. > > All the !paravirt patches are more or less the same as before (the only real > change is the copyright lines in the first patch). > > The paravirt stuff is 'simple' and KVM only -- the Xen code was a

On Thu, Mar 26, 2015 at 09:21:53PM +0100, Peter Zijlstra wrote: > On Wed, Mar 25, 2015 at 03:47:39PM -0400, Konrad Rzeszutek Wilk wrote: > > Ah nice. That could be spun out as a seperate patch to optimize the existing > > ticket locks I presume. > > Yes I suppose we can do something similar for the ticket and patch in > the right increment. We'd need to restructure the

On Mon, Mar 30, 2015 at 12:25:12PM -0400, Waiman Long wrote: > I did it differently in my PV portion of the qspinlock patch. Instead of > just waking up the CPU, the new lock holder will check if the new queue head > has been halted. If so, it will set the slowpath flag for the halted queue > head in the lock so as to wake it up at unlock time. This should eliminate > your concern

Hi, I tested nutdrv_qx additions, introduced by @zykh, for a couple of months now and changed only small things. You can reach the repository via [1]. Please review the item_t array (starting at [2]) and give me feedback, or change it directly. Missing is the complete documentation, which I'm trying to get time for since the last six months, but I don't. Best, Nick [1]

On 07/04/15 03:55, Waiman Long wrote: > This patch adds the necessary Xen specific code to allow Xen to > support the CPU halting and kicking operations needed by the queue > spinlock PV code. This basically looks the same as the version I wrote, except I think you broke it. > +static void xen_qlock_wait(u8 *byte, u8 val) > +{ > + int irq = __this_cpu_read(lock_kicker_irq);

On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote: > For a virtual guest with the qspinlock patch, a simple unfair byte lock > will be used if PV spinlock is not configured in or the hypervisor > isn't either KVM or Xen. The byte lock works fine with small guest > of just a few vCPUs. On a much larger guest, however, byte lock can > have serious performance problem.

On Thu, Apr 09, 2015 at 09:16:24AM -0400, Rik van Riel wrote: > On 04/09/2015 03:01 AM, Peter Zijlstra wrote: > > On Wed, Apr 08, 2015 at 02:32:19PM -0400, Waiman Long wrote: > >> For a virtual guest with the qspinlock patch, a simple unfair byte lock > >> will be used if PV spinlock is not configured in or the hypervisor > >> isn't either KVM or Xen. The

On Thu, Apr 09, 2015 at 08:13:27PM +0200, Peter Zijlstra wrote: > On Mon, Apr 06, 2015 at 10:55:44PM -0400, Waiman Long wrote: > > +#define PV_HB_PER_LINE (SMP_CACHE_BYTES / sizeof(struct pv_hash_bucket)) > > +static struct qspinlock **pv_hash(struct qspinlock *lock, struct pv_node *node) > > +{ > > + unsigned long init_hash, hash = hash_ptr(lock, pv_lock_hash_bits);

Dont support 'MAP_SYNC' with non-DAX files and DAX files with asynchronous dax_device. Virtio pmem provides asynchronous host page cache flush mechanism. We don't support 'MAP_SYNC' with virtio pmem and ext4. Signed-off-by: Pankaj Gupta <pagupta at redhat.com> Reviewed-by: Jan Kara <jack at suse.cz> --- fs/ext4/file.c | 10 ++++++---- 1 file changed, 6

On 07/04/15 03:55, Waiman Long wrote: > This patch adds the necessary Xen specific code to allow Xen to > support the CPU halting and kicking operations needed by the queue > spinlock PV code. This basically looks the same as the version I wrote, except I think you broke it. > +static void xen_qlock_wait(u8 *byte, u8 val) > +{ > + int irq = __this_cpu_read(lock_kicker_irq);

Am 27.08.23 um 19:54 schrieb Dmitry Osipenko: > Add simple kref_put_dma_resv() helper that wraps around kref_put_ww_mutex() > for drivers that needs to lock dma-resv on kref_put(). > > It's not possible to easily add this helper to kref.h because of the > headers inclusion dependency, hence add it to dma-resv.h. I was never really a big fan of kref_put_mutex() in the first