[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH-4.5 3/4] xen/arm: do not request maintenance_interrupts
On Mon, 10 Feb 2014, Ian Campbell wrote: > On Mon, 2014-02-10 at 17:16 +0000, Stefano Stabellini wrote: > > On Mon, 10 Feb 2014, Ian Campbell wrote: > > > On Mon, 2014-02-10 at 17:06 +0000, Stefano Stabellini wrote: > > > > On Fri, 7 Feb 2014, Julien Grall wrote: > > > > > On 07/02/14 18:56, Stefano Stabellini wrote: > > > > > > +static void gic_clear_lrs(struct vcpu *v) > > > > > > +{ > > > > > > + struct pending_irq *p; > > > > > > + int i = 0, irq; > > > > > > + uint32_t lr; > > > > > > + bool_t inflight; > > > > > > + > > > > > > + ASSERT(!local_irq_is_enabled()); > > > > > > + > > > > > > + while ((i = find_next_bit((const long unsigned int *) > > > > > > &this_cpu(lr_mask), > > > > > > + nr_lrs, i)) < nr_lrs) { > > > > > > > > > > Did you look at to ELRSR{0,1} registers which list the usable LRs? I > > > > > think you > > > > > can use it with the this_cpu(lr_mask) to avoid browsing every LRs. > > > > > > > > Given that we only have 4 LR registers, I think that unconditionally > > > > reading 2 ELRSR registers would cost more than simply checking lr_mask > > > > on average. > > > > > > You also need to actually read the LR and do some bit masking etc don't > > > you? > > > > No bit masking but I need to read the LRs, that are just 4. > > Having read them then what do you do with the result? Surely you need to > examine some or all of the bits to determine if it is free or not? Right: if ( !(lr & (GICH_LR_PENDING|GICH_LR_ACTIVE)) ) I thought you meant we need to write back a masked value. > > > What about implementations with >4 LRs? > > > > I could read ELRSR only if nr_lrs > 8 or something like that. > > That would be the worst of both worlds IMHO. On second thought you are right: if we always clear the LRs, the logic is simpler and may be slower with an high number of LRs and concurrent irqs. If we don't clear all the LRs on return to guest and use ELRSR to filter them, we are slower with a small number of LRs / concurrent irqs, faster with an high number of LRs and concurrent irqs but the code would be much more complex. Overall checking for nr_lrs > 8 would add too much complexity for little benefit. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |