search for: busywaiting

So, I'm seeing XMMS behave mighty strangely here. decode_example piped into a command line player manages to playback realtime on my p233 somewhat easily. XMMS (with the Vorbis plugin) utterly pegs the CPU and stutters badly. So, I started playing. Playing back mp3, xmms stutters badly (mp123 and xaudio play back realtime without difficulty). Playing back straight wav files, xmms also

Hi all, I have an icecast setup with 20+ sources. During peak times some 20 sources will be connected with a total of some 250 listeners more-or-less equally divided over the 20 sources. All streams are running at a measly 16 kbps. There is enough bandwidth to/from the server. During these peak times I see very high CPU usage for icecast 98-99%. The system I'm running is an Intel Celeron

On Wed, Jul 12, 2017 at 08:40:18PM +0800, Wei Wang wrote: > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index 28b0e96..9f27101 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -57,8 +57,28 @@ int virtqueue_add_sgs(struct virtqueue *vq, > void *data, > gfp_t gfp); > > +/* A desc with this init id is treated

On Wed, Jul 12, 2017 at 08:40:18PM +0800, Wei Wang wrote: > diff --git a/include/linux/virtio.h b/include/linux/virtio.h > index 28b0e96..9f27101 100644 > --- a/include/linux/virtio.h > +++ b/include/linux/virtio.h > @@ -57,8 +57,28 @@ int virtqueue_add_sgs(struct virtqueue *vq, > void *data, > gfp_t gfp); > > +/* A desc with this init id is treated

Add a new vq to report hints of guest free pages to the host. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Signed-off-by: Liang Li <liang.z.li at intel.com> --- drivers/virtio/virtio_balloon.c | 164 ++++++++++++++++++++++++++++++------ include/uapi/linux/virtio_balloon.h | 1 + 2 files changed, 140 insertions(+), 25 deletions(-) diff --git

> > Add a new vq to report hints of guest free pages to the host. > > Signed-off-by: Wei Wang <wei.w.wang at intel.com> > Signed-off-by: Liang Li <liang.z.li at intel.com> > --- > drivers/virtio/virtio_balloon.c | 164 > ++++++++++++++++++++++++++++++------ > include/uapi/linux/virtio_balloon.h | 1 + > 2 files changed, 140 insertions(+), 25

> > Add a new vq to report hints of guest free pages to the host. > > Signed-off-by: Wei Wang <wei.w.wang at intel.com> > Signed-off-by: Liang Li <liang.z.li at intel.com> > --- > drivers/virtio/virtio_balloon.c | 164 > ++++++++++++++++++++++++++++++------ > include/uapi/linux/virtio_balloon.h | 1 + > 2 files changed, 140 insertions(+), 25

From: Ben Skeggs <bskeggs at redhat.com> There was at least one situation we could get into in the old code where we'd end up overrunning the push buffer with the jumps back to the start of the buffer in an attempt to get more space. In addition, the new code prevents misdetecting a GPU hang by resetting the timeout counter if we see the GPU GET pointer advancing, and simplifies the

...but at cost of e.g. transparently busy-waiting. Unlikely to be > a good fit for anything else. If you were referring to this API - virtqueue_add_chain_desc(): Busy waiting only happens when the vq is full (i.e. no desc left). If necessary, I think we can add an input parameter like "bool busywaiting", then the caller can decide to simply get a -ENOSPC or busy wait to add when no desc is available. > > If you don't like my original _first/_next/_last, you will > need to come up with something else. I thought the above virtqueue_add_chain_des() performs the same functionality...

On Mon, 2005-03-07 at 22:01, Klaas Jan Wierenga wrote: > Hi all, > > I have an icecast setup with 20+ sources. During peak times some 20 sources > will be connected with a total of some 250 listeners more-or-less equally > divided over the 20 sources. All streams are running at a measly 16 kbps. > There is enough bandwidth to/from the server. During these peak times I see >

Forgive this intrusion, but I couldn't find much mention of this in the archives. To reduce vulnerability to "Keystroke Timing Attack" and reduce keystroke packet overhead, why not insert a small configurable delay (10-1000ms) before sending keystroke packets?`ssh -d NNN` Yes, this costs latency. But many netlinks are already 200+ms and latency isn't always objectionable in a

...up a currently halted VCPU of its choice, see Documentation/virtual/kvm/hypercalls.txt. 5. KVM_HC_KICK_CPU ------------------------ Architecture: x86 Status: active Purpose: Hypercall used to wakeup a vcpu from HLT state Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest kernel mode for an event to occur (ex: a spinlock to become available) can execute HLT instruction once it has busy-waited for more than a threshold time-interval. Execution of HLT instruction would cause the hypervisor to put the vcpu to sleep until occurrence of an appropria...

...est can map this shared page to access its supervisor register through memory using this hypercall. + +5. KVM_HC_KICK_CPU +------------------------ +Architecture: x86 +Status: active +Purpose: Hypercall used to wakeup a vcpu from HLT state +Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest +kernel mode for an event to occur (ex: a spinlock to become available) can +execute HLT instruction once it has busy-waited for more than a threshold +time-interval. Execution of HLT instruction would cause the hypervisor to put +the vcpu to sleep until occurence of an appropriate event....

...samples going to the DAC. This isn't something you have to "feel", it's something you could _measure_? far more precisely than anyone could hope to hear. To whatever extent that were true, it would also be true of 1000 other possible CPU load sources, including operating systems busywaiting on the disk, differences in display device drivers, etc. In fact, considering how massively slow disk IO is compared to FLAC decompression it seems just as plausible that the increased disk IO (with the resulting PCI traffic and IO blocking) caused by uncompressed playback makes audible glitches...

On Monday 14 July 2008 21:51:25 Christian Borntraeger wrote: > Am Montag, 14. Juli 2008 schrieb Hidetoshi Seto: > > + /* Wait all others come to life */ > > + while (cpus_weight(prepared_cpus) != num_online_cpus() - 1) { > > + if (time_is_before_jiffies(limit)) > > + goto timeout; > > + cpu_relax(); > > + } > > + > > Hmm. I think this could

On Monday 14 July 2008 21:51:25 Christian Borntraeger wrote: > Am Montag, 14. Juli 2008 schrieb Hidetoshi Seto: > > + /* Wait all others come to life */ > > + while (cpus_weight(prepared_cpus) != num_online_cpus() - 1) { > > + if (time_is_before_jiffies(limit)) > > + goto timeout; > > + cpu_relax(); > > + } > > + > > Hmm. I think this could

...v23: > - change to kick the device when the vq is half-way full; > - open-code batch_free_page_sg into add_one_sg; > - change cmd_id from "uint32_t" to "__virtio32"; > - reserver one entry in the vq for teh driver to send cmd_id, instead > of busywaiting for an available entry; > - add "stop_update" check before queue_work for prudence purpose for > now, will have a separate patch to discuss this flag check later; > - init_vqs: change to put some variables on stack to have simpler > implementation; >...

On 26/02/14 15:14, Waiman Long wrote: > This patch adds para-virtualization support to the queue spinlock code > by enabling the queue head to kick the lock holder CPU, if known, > in when the lock isn't released for a certain amount of time. It > also enables the mutual monitoring of the queue head CPU and the > following node CPU in the queue to make sure that their CPUs will

On 26/02/14 15:14, Waiman Long wrote: > This patch adds para-virtualization support to the queue spinlock code > by enabling the queue head to kick the lock holder CPU, if known, > in when the lock isn't released for a certain amount of time. It > also enables the mutual monitoring of the queue head CPU and the > following node CPU in the queue to make sure that their CPUs will

...v23: > - change to kick the device when the vq is half-way full; > - open-code batch_free_page_sg into add_one_sg; > - change cmd_id from "uint32_t" to "__virtio32"; > - reserver one entry in the vq for the driver to send cmd_id, instead > of busywaiting for an available entry; > - add "stop_update" check before queue_work for prudence purpose for > now, will have a separate patch to discuss this flag check later; > - init_vqs: change to put some variables on stack to have simpler > implementation; >...