linux-kernel - Re: [patch] sched: add locking when update the task_group's cfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Nov 2008 00:22:22 -0800
From:	Ken Chen <kenchen@...gle.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] sched: add locking when update the task_group's cfs_rq[] 
	array.

On Tue, Nov 18, 2008 at 11:53 PM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Ken Chen <kenchen@...gle.com> wrote:
>
>> @@ -1513,8 +1513,12 @@ static int tg_shares_up
>>       unsigned long weight, rq_weight = 0;
>>       unsigned long shares = 0;
>>       struct sched_domain *sd = data;
>> +     unsigned long flags;
>>       int i;
>>
>> +     if (!spin_trylock_irqsave(&tg->tg_lock, flags))
>> +             return 0;
>
> hm, why trylock?

I'm paranoid about potential lock contention.  Considering calls to
tg_shares_up() are more or less sample based, I opt to skip updating
if there is a lock contention.  Though kernel only walks tg tree every
sysctl_sched_shares_ratelimit.  Maybe chances of running into lock
contention isn't that high anyway, in which case trylock will mostly
able to get the lock.

- Ken
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/