From: Avi Kivity <avi@redhat.com> To: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, Mark Langsdorf <mark.langsdorf@amd.com>, Joerg Roedel <joerg.roedel@amd.com>, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM Date: Mon, 11 May 2009 17:24:57 +0300 [thread overview] Message-ID: <4A083539.407@redhat.com> (raw) In-Reply-To: <20090511141503.GC6175@elte.hu> Ingo Molnar wrote: > >>> +static int pause_interception(struct vcpu_svm *svm, struct kvm_run >>> *kvm_run) >>> +{ >>> + /* Simple yield */ >>> + vcpu_put(&svm->vcpu); >>> + schedule(); >>> + vcpu_load(&svm->vcpu); >>> + return 1; >>> + >>> >> Ingo, will this do anything under CFS, or will CFS note that >> nothing has changed in the accounting and reschedule us >> immediately? >> > > The scheduler will yield to another task only if the current task > has become ineligible. I.e schedule() is largely a NOP on > TASK_RUNNING tasks (i.e. here). > Especially on preemptible kernels, where the schedule() would have already happened if it could cause anything, IIUC. > I.e. this is a somewhat poor solution as far as scheduling goes. But > i'm wondering what the CPU side does. Can REP-NOP really take > thousands of cycles? If yes, under what circumstances? > The guest is running rep-nop in a loop while trying to acquire a spinlock. The hardware detects this (most likely, repeated rep-nop with the same rip) and exits. We can program the loop count; obviously if we're spinning for only a short while it's better to keep spinning while hoping the lock will be released soon. The idea is to detect that the guest is not making forward progress and yield. If I could tell the scheduler, you may charge me a couple of milliseconds, I promise not to sue, that would be ideal. Other tasks can become eligible, hopefully the task holding the spinlock, and by the time we're scheduled back the long running task will have finished and released the lock. For newer Linux as a guest we're better off paravirtualizing this, so we can tell the host which vcpu holds the lock; in this case kvm will want to say, take a couple milliseconds off my account and transfer it to this task (so called directed yield). However there's no reason to paravirtualize all cpu_relax() calls. -- error compiling committee.c: too many arguments to function
WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com> To: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, Mark Langsdorf <mark.langsdorf@amd.com>, Joerg Roedel <joerg.roedel@amd.com>, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH][retry 1] Add support for Pause Filtering to AMD SVM Date: Mon, 11 May 2009 17:24:57 +0300 [thread overview] Message-ID: <4A083539.407@redhat.com> (raw) In-Reply-To: <20090511141503.GC6175@elte.hu> Ingo Molnar wrote: > >>> +static int pause_interception(struct vcpu_svm *svm, struct kvm_run >>> *kvm_run) >>> +{ >>> + /* Simple yield */ >>> + vcpu_put(&svm->vcpu); >>> + schedule(); >>> + vcpu_load(&svm->vcpu); >>> + return 1; >>> + >>> >> Ingo, will this do anything under CFS, or will CFS note that >> nothing has changed in the accounting and reschedule us >> immediately? >> > > The scheduler will yield to another task only if the current task > has become ineligible. I.e schedule() is largely a NOP on > TASK_RUNNING tasks (i.e. here). > Especially on preemptible kernels, where the schedule() would have already happened if it could cause anything, IIUC. > I.e. this is a somewhat poor solution as far as scheduling goes. But > i'm wondering what the CPU side does. Can REP-NOP really take > thousands of cycles? If yes, under what circumstances? > The guest is running rep-nop in a loop while trying to acquire a spinlock. The hardware detects this (most likely, repeated rep-nop with the same rip) and exits. We can program the loop count; obviously if we're spinning for only a short while it's better to keep spinning while hoping the lock will be released soon. The idea is to detect that the guest is not making forward progress and yield. If I could tell the scheduler, you may charge me a couple of milliseconds, I promise not to sue, that would be ideal. Other tasks can become eligible, hopefully the task holding the spinlock, and by the time we're scheduled back the long running task will have finished and released the lock. For newer Linux as a guest we're better off paravirtualizing this, so we can tell the host which vcpu holds the lock; in this case kvm will want to say, take a couple milliseconds off my account and transfer it to this task (so called directed yield). However there's no reason to paravirtualize all cpu_relax() calls. -- error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-05-11 14:25 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-05-05 14:09 [PATCH][KVM] Add support for Pause Filtering to AMD SVM Mark Langsdorf 2009-05-05 16:05 ` Bert Wesarg 2009-05-07 13:55 ` Joerg Roedel 2009-05-07 15:00 ` [PATCH][KVM][retry 1] " Mark Langsdorf 2009-05-07 15:00 ` [PATCH][retry " Mark Langsdorf 2009-05-07 15:31 ` [PATCH][KVM][retry " Avi Kivity 2009-05-11 14:15 ` Ingo Molnar 2009-05-11 14:15 ` [PATCH][retry " Ingo Molnar 2009-05-11 14:24 ` Avi Kivity [this message] 2009-05-11 14:24 ` Avi Kivity 2009-05-11 14:33 ` [PATCH][KVM][retry " Ingo Molnar 2009-05-11 14:33 ` [PATCH][retry " Ingo Molnar 2009-05-11 14:51 ` [PATCH][KVM][retry " Avi Kivity 2009-05-11 14:51 ` [PATCH][retry " Avi Kivity 2009-05-11 14:59 ` [PATCH][KVM][retry " Ingo Molnar 2009-05-11 14:59 ` [PATCH][retry " Ingo Molnar 2009-05-11 15:12 ` [PATCH][KVM][retry " Avi Kivity 2009-05-11 15:12 ` [PATCH][retry " Avi Kivity 2009-05-11 15:18 ` [PATCH][KVM][retry " Ingo Molnar 2009-05-11 15:18 ` [PATCH][retry " Ingo Molnar 2009-05-11 15:28 ` [PATCH][KVM][retry " Avi Kivity 2009-05-11 15:28 ` [PATCH][retry " Avi Kivity 2009-05-11 15:36 ` [PATCH][KVM][retry " Langsdorf, Mark 2009-05-11 15:36 ` [PATCH][retry " Langsdorf, Mark 2009-05-11 15:40 ` [PATCH][KVM][retry " Avi Kivity 2009-05-11 15:58 ` [PATCH][KVM][retry 1] Add support for Pause Filtering to AMDSVM Langsdorf, Mark 2009-05-11 15:58 ` [PATCH][retry " Langsdorf, Mark 2009-05-11 15:01 ` [PATCH][KVM][retry 1] Add support for Pause Filtering to AMD SVM Peter Zijlstra 2009-05-11 15:01 ` [PATCH][retry " Peter Zijlstra 2009-05-11 15:06 ` [PATCH][KVM][retry " Avi Kivity 2009-05-11 15:06 ` [PATCH][retry " Avi Kivity 2009-05-11 14:42 ` [PATCH][KVM][retry " Peter Zijlstra 2009-05-11 15:05 ` Avi Kivity 2009-05-11 15:05 ` [PATCH][retry " Avi Kivity 2009-05-08 17:03 ` [PATCH][KVM][retry 2] " Mark Langsdorf 2009-05-08 17:03 ` [PATCH][retry " Mark Langsdorf 2009-05-08 18:44 ` [PATCH][KVM][retry " Avi Kivity 2009-05-08 18:44 ` [PATCH][retry " Avi Kivity 2009-05-08 18:47 ` [PATCH][KVM][retry " Langsdorf, Mark 2009-05-08 18:47 ` [PATCH][retry " Langsdorf, Mark 2009-05-19 18:56 ` [PATCH][KVM][retry 3] " Mark Langsdorf 2009-05-19 18:56 ` [PATCH][retry " Mark Langsdorf 2009-05-20 7:40 ` [PATCH][KVM][retry " Ingo Molnar 2009-05-20 7:59 ` Peter Zijlstra 2009-05-20 7:59 ` [PATCH][retry " Peter Zijlstra 2009-05-20 8:38 ` [PATCH][KVM][retry " Avi Kivity 2009-05-20 8:38 ` [PATCH][retry " Avi Kivity 2009-05-20 8:42 ` [PATCH][KVM][retry " Peter Zijlstra 2009-05-20 8:42 ` [PATCH][retry " Peter Zijlstra 2009-05-20 8:49 ` [PATCH][KVM][retry " Avi Kivity 2009-05-20 8:49 ` [PATCH][retry " Avi Kivity 2009-05-20 8:54 ` [PATCH][KVM][retry " Peter Zijlstra 2009-05-20 8:54 ` [PATCH][retry " Peter Zijlstra 2009-05-20 9:04 ` [PATCH][KVM][retry " Avi Kivity 2009-05-20 9:04 ` [PATCH][retry " Avi Kivity 2009-05-20 9:10 ` [PATCH][KVM][retry " Peter Zijlstra 2009-05-20 9:10 ` [PATCH][retry " Peter Zijlstra 2009-05-20 9:17 ` [PATCH][KVM][retry " Avi Kivity 2009-05-20 9:17 ` [PATCH][retry " Avi Kivity 2009-05-20 13:52 ` [PATCH][KVM][retry " Langsdorf, Mark 2009-05-20 13:52 ` [PATCH][retry " Langsdorf, Mark 2009-05-20 12:00 ` [PATCH][KVM][retry " Avi Kivity 2009-05-20 12:00 ` [PATCH][retry " Avi Kivity 2009-05-20 22:25 ` [PATCH][KVM][retry 4] " Mark Langsdorf 2009-05-20 22:25 ` [PATCH][retry " Mark Langsdorf 2009-05-21 8:47 ` [PATCH][KVM][retry " Avi Kivity 2009-05-21 8:47 ` [PATCH][retry " Avi Kivity 2009-07-08 5:19 ` [PATCH][KVM][retry " Sheng Yang 2009-07-08 5:19 ` [PATCH][retry " Sheng Yang 2009-07-08 14:59 ` [PATCH][KVM][retry " Langsdorf, Mark 2009-07-08 14:59 ` [PATCH][retry " Langsdorf, Mark 2009-07-09 1:50 ` [PATCH][KVM][retry " Sheng Yang 2009-07-09 1:50 ` [PATCH][retry " Sheng Yang 2009-07-22 22:40 ` [PATCH][KVM][retry " Langsdorf, Mark 2009-07-22 22:40 ` [PATCH][retry " Langsdorf, Mark 2009-08-05 9:08 ` [PATCH][KVM][retry " Zhai, Edwin 2009-08-05 9:08 ` [PATCH][retry " Zhai, Edwin 2009-05-11 14:38 ` [PATCH][KVM] " Peter Zijlstra 2009-05-11 14:51 ` Ingo Molnar
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4A083539.407@redhat.com \ --to=avi@redhat.com \ --cc=a.p.zijlstra@chello.nl \ --cc=joerg.roedel@amd.com \ --cc=kvm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.langsdorf@amd.com \ --cc=mingo@elte.hu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.