All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Haskins <gregory.haskins@gmail.com>
To: Avi Kivity <avi@redhat.com>
Cc: Gregory Haskins <ghaskins@novell.com>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	alacrityvm-devel@lists.sourceforge.net
Subject: Re: [Alacrityvm-devel] [KVM PATCH v2 1/2] KVM: export lockless GSI attribute
Date: Wed, 28 Oct 2009 09:19:54 -0400	[thread overview]
Message-ID: <4AE844FA.4070408@gmail.com> (raw)
In-Reply-To: <4AE81710.1080103@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

Avi Kivity wrote:
> On 10/26/2009 05:38 PM, Gregory Haskins wrote:
>>>> Instead of a lockless attribute, how about a ->set_atomic() method. 
>>>> For
>>>> msi this can be the same as ->set(), for non-msi it can be a function
>>>> that schedules the work (which will eventually call ->set()).
>>>>
>>>> The benefit is that we make a decision only once, when preparing the
>>>> routing entry, and install that decision in the routing entry
>>>> instead of
>>>> making it again and again later.
>>>>        
>>> Yeah, I like this idea.  I think we can also get rid of the custom
>>> workqueue if we do this as well, TBD.
>>>      
>> So I looked into this.  It isn't straight forward because you need to
>> retain some kind of state across the deferment on a per-request basis
>> (not per-GSI).  Today, this state is neatly tracked into the irqfd
>> object itself (e.g. it knows to toggle the GSI).
>>    
> 
> Yes, and it also contains the work_struct.
> 
> What if we make the work_struct (and any additional state) part of the
> set_atomic() argument list?  Does it simplify things?

Hmmm, that might not, but we could do a kmalloc(GFP_ATOMIC) for such
parameters.  Considering this is just a safety net, perhaps this would
work fine.

> 
>> So while generalizing this perhaps makes sense at some point, especially
>> if irqfd-like interfaces get added, it probably doesn't make a ton of
>> sense to expend energy on it ATM.  It is basically a generalization of
>> the irqfd deferrment code.  Lets just wait until we have a user beyond
>> irqfd for now.  Sound acceptable?
>>    
> 
> I'll look at v3, but would really like to disentangle this.

Ok, I will see what I can do.  I need at least a v4 to get rid of the
dependency on the now defunct v3:1/3 patch per yesterdays discussion.

Kind Regards,
-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]

  reply	other threads:[~2009-10-28 13:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-23  2:38 [KVM PATCH v2 0/2] irqfd enhancements Gregory Haskins
2009-10-23  2:38 ` [KVM PATCH v2 1/2] KVM: export lockless GSI attribute Gregory Haskins
2009-10-23  2:43   ` Gregory Haskins
2009-10-25 14:30   ` Avi Kivity
2009-10-26 13:25     ` [Alacrityvm-devel] " Gregory Haskins
2009-10-26 15:38       ` Gregory Haskins
2009-10-28 10:04         ` Avi Kivity
2009-10-28 13:19           ` Gregory Haskins [this message]
2009-10-28 13:27             ` Avi Kivity
2009-10-28 13:30               ` Gregory Haskins
2009-10-23  2:38 ` [KVM PATCH v2 2/2] KVM: Directly inject interrupts if they support lockless operation Gregory Haskins

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=4AE844FA.4070408@gmail.com \
    --to=gregory.haskins@gmail.com \
    --cc=alacrityvm-devel@lists.sourceforge.net \
    --cc=avi@redhat.com \
    --cc=ghaskins@novell.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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: link
Be 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.