mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Cheng Chao <cs.os.kernel@gmail.com>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: tglx@linutronix.de, jason@lakedaemon.net,
	linux-kernel@vger.kernel.org, cs.os.kernel@gmail.com
Subject: Re: [PATCH] irqchip/gic: Enable gic_set_affinity set more than one cpu
Date: Fri, 14 Oct 2016 10:08:10 +0800	[thread overview]
Message-ID: <1c4adb8a-f7f7-3474-273a-edf34f575b8d@gmail.com> (raw)
In-Reply-To: <20161013163140.5f23abce@arm.com>

Marc,

  Thanks for your comments.

Cheng

on 10/13/2016 11:31 PM, Marc Zyngier wrote:
> On Thu, 13 Oct 2016 18:57:14 +0800
> Cheng Chao <cs.os.kernel@gmail.com> wrote:
> 
>> GIC can distribute an interrupt to more than one cpu,
>> but now, gic_set_affinity sets only one cpu to handle interrupt.
> 
> What makes you think this is a good idea? What purpose does it serves?
> I can only see drawbacks to this: You're waking up more than one CPU,
> wasting power, adding jitter and clobbering the cache.
>
> I assume you see a benefit to that approach, so can you please spell it
> out?
>

Ok, You are right, but the performance is another point that we should consider. 

We use E1 device to transmit/receive video stream. we find that E1's interrupt is
only on the one cpu that cause this cpu usage is almost 100%, 
but other cpus is much lower load, so the performance is not good.
the cpu is 4-core.


so add CONFIG_ARM_GIC_AFFINITY_SINGLE_CPU is better?
thus we can make a trade-off between the performance with the power etc.


>>
>> Signed-off-by: Cheng Chao <cs.os.kernel@gmail.com>
>> ---
>>  drivers/irqchip/irq-gic.c | 28 ++++++++++++++++++++++++----
>>  1 file changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>> index 58e5b4e..198d33f 100644
>> --- a/drivers/irqchip/irq-gic.c
>> +++ b/drivers/irqchip/irq-gic.c
>> @@ -328,18 +328,38 @@ static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>>  	unsigned int cpu, shift = (gic_irq(d) % 4) * 8;
>>  	u32 val, mask, bit;
>>  	unsigned long flags;
>> +	u32 valid_mask;
>>  
>> -	if (!force)
>> -		cpu = cpumask_any_and(mask_val, cpu_online_mask);
>> -	else
>> +	if (!force) {
>> +		valid_mask = cpumask_bits(mask_val)[0];
>> +		valid_mask &= cpumask_bits(cpu_online_mask)[0];
>> +
>> +		cpu = cpumask_any((struct cpumask *)&valid_mask);
> 
> What is wrong with with cpumask_any_and?
> 

#define cpumask_any_and(mask1, mask2) cpumask_first_and((mask1), (mask2))
#define cpumask_any(srcp) cpumask_first(srcp)

There is no wrong with the cpumask_any_and. 

>> +	} else {
>>  		cpu = cpumask_first(mask_val);
>> +	}
>>  
>>  	if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids)
>>  		return -EINVAL;
>>  
>>  	gic_lock_irqsave(flags);
>>  	mask = 0xff << shift;
>> -	bit = gic_cpu_map[cpu] << shift;
>> +
>> +	if (!force) {
>> +		bit = 0;
>> +
>> +		for_each_cpu(cpu, (struct cpumask *)&valid_mask) {
>> +			if (cpu >= NR_GIC_CPU_IF || cpu >= nr_cpu_ids)
>> +				break;
> 
> Shouldn't that be an error?
> 

tested, no error.

at the beginning, I code such like,

cpumask_var_t valid_mask;
alloc_cpumask_var(&valid_mask, GFP_KERNEL);
cpumask_and(valid_mask, mask_val, cpu_online_mask);
for_each_cpu(cpu, valid_mask) {

}

but alloc_cpumask_var maybe fail, so 
if (!alloc_cpumask_var(&valid_mask, GFP_KERNEL)) {
  /* fail*/

} else {

}

a little more complex.

>> +
>> +			bit |= gic_cpu_map[cpu];
>> +		}
>> +
>> +		bit = bit << shift;
>> +	} else {
>> +		bit = gic_cpu_map[cpu] << shift;
>> +	}
>> +
>>  	val = readl_relaxed(reg) & ~mask;
>>  	writel_relaxed(val | bit, reg);
>>  	gic_unlock_irqrestore(flags);
> 
> Thanks,
> 
> 	M.
> 

  reply	other threads:[~2016-10-14  2:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 10:57 Cheng Chao
2016-10-13 11:11 ` Cheng Chao
2016-10-13 15:31 ` Marc Zyngier
2016-10-14  2:08   ` Cheng Chao [this message]
2016-10-14 17:33     ` Marc Zyngier
2016-10-15  7:23       ` Cheng Chao
2016-10-25 10:09         ` Marc Zyngier
2016-10-26  2:04           ` Cheng Chao

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=1c4adb8a-f7f7-3474-273a-edf34f575b8d@gmail.com \
    --to=cs.os.kernel@gmail.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=tglx@linutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®