search for: need_reshed

If we read hwrng by long-running dd process, it takes too much cpu time and almost hold the mutex lock. When we check hwrng attributes from sysfs by cat, it gets stuck in waiting the lock releaseing. The problem can only be reproduced with non-smp guest with slow backend. This patchset resolves the issue by changing rng_dev_read() to always schedule 10 jiffies after release mutex lock, then cat

If we read hwrng by long-running dd process, it takes too much cpu time and almost hold the mutex lock. When we check hwrng attributes from sysfs by cat, it gets stuck in waiting the lock releaseing. The problem can only be reproduced with non-smp guest with slow backend. This patchset resolves the issue by changing rng_dev_read() to always schedule 10 jiffies after release mutex lock, then cat

...s need to be run, but it almost always return false, and re-hold the mutex lock. The attributes accessing process always fails to hold the lock, so the cat gets stuck. User context doesn't allow other user contexts run on that CPU, unless the kernel code sleeps for some reason. This is why the need_reshed() always return false here. This patch removed need_resched() and always schedule other tasks then other tasks can have chance to hold the lock and execute protected code. Signed-off-by: Amos Kong <akong at redhat.com> --- drivers/char/hw_random/core.c | 3 +-- 1 file changed, 1 insertion(...

...st always return false, and re-hold the mutex > lock. The attributes accessing process always fails to hold the > lock, so the cat gets stuck. > > User context doesn't allow other user contexts run on that CPU, > unless the kernel code sleeps for some reason. This is why the > need_reshed() always return false here. > > This patch removed need_resched() and always schedule other tasks > then other tasks can have chance to hold the lock and execute > protected code. OK, this is going to be a rant. Your explanation doesn't make sense at all. Worse, your solution bre...

...st always return false, and re-hold the mutex > lock. The attributes accessing process always fails to hold the > lock, so the cat gets stuck. > > User context doesn't allow other user contexts run on that CPU, > unless the kernel code sleeps for some reason. This is why the > need_reshed() always return false here. > > This patch removed need_resched() and always schedule other tasks > then other tasks can have chance to hold the lock and execute > protected code. OK, this is going to be a rant. Your explanation doesn't make sense at all. Worse, your solution bre...

...onfiguration. The following interrupts are supported: SIGP STOP - interprocessor signal that stops a remote cpu SIGP SET PREFIX - interprocessor signal that sets the prefix register of a (stopped) remote cpu INT EMERGENCY - interprocessor interrupt, usually used to signal need_reshed and for smp_call_function() in the guest. PROGRAM INT - exception during program execution such as page fault, illegal instruction and friends RESTART - interprocessor signal that starts a stopped cpu INT VIRTIO - floating interrupt for virtio si...

This patch series introduces a backend for kvm to run on IBM System z machines that uses the mainframe's sie virtualization capability. This work runs 64bit guests on z800/z890/z900/z990/z9/z10 class machines with a 64bit linux host. Userspace will follow once we're done brushing it over. The patch queue consists of the following patches, which can be applied in sequence on top of kvm.git

This patch series introduces a backend for kvm to run on IBM System z machines that uses the mainframe's sie virtualization capability. This work runs 64bit guests on z800/z890/z900/z990/z9/z10 class machines with a 64bit linux host. Userspace will follow once we're done brushing it over. The patch queue consists of the following patches, which can be applied in sequence on top of kvm.git