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]
Message-ID: <2ea3687e-b5a9-4de3-99d2-261bccb06c0b@linux.ibm.com>
Date: Thu, 20 Mar 2025 10:11:00 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: linux-kernel@...r.kernel.org, Dietmar Eggemann
 <dietmar.eggemann@....com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Valentin Schneider <vschneid@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>, Mel Gorman <mgorman@...e.de>,
        Vincent Guittot <vincent.guittot@...aro.org>
Subject: Re: [PATCH 0/5] sched: Make CONFIG_SCHED_DEBUG features unconditional



On 3/20/25 02:44, Ingo Molnar wrote:
> 
> * Shrikanth Hegde <sshegde@...ux.ibm.com> wrote:
> 
>>
>>
>> On 3/17/25 16:12, Ingo Molnar wrote:
>>> For more than a decade, CONFIG_SCHED_DEBUG=y has been enabled
>>> in all the major Linux distributions:
>>>
>>>      /boot/config-6.11.0-19-generic:CONFIG_SCHED_DEBUG=y
>>>
>>> The reason is that while originally CONFIG_SCHED_DEBUG started
>>> out as a debugging feature, over the years (decades ...) it has
>>> grown various bits of statistics, instrumentation and
>>> control knobs that are useful for sysadmin and general software
>>> development purposes as well.
>>
>> A tunable like base_slice which is the only tunable available for EEVDF is under the debug.
>> So an option is to get rid of CONFIG_SCHED_DEBUG and make it available to all.
>>
>> We had seen performance regression when domains folder was built with cpu hotplug.
>> Later that was moved iff verbose was enabled. Maybe something like that can be done
>> if something is hurting performance.
>>
>>>
>>> But within the kernel we still pretend that there's a choice,
>>> and sometimes code that is seemingly 'debug only' creates overhead
>>> that should be optimized in reality.
>>>
>>> So make it all official and make CONFIG_SCHED_DEBUG unconditional.
>>> This gets rid of a large amount of #ifdefs, so good riddance ...
>>>
>>
>> There are some references in selftest like these, maybe remove them as well?
>>
>> tools/testing/selftests/sched_ext/config:CONFIG_SCHED_DEBUG=y
>> tools/testing/selftests/sched/config:CONFIG_SCHED_DEBUG=y
>> tools/testing/selftests/wireguard/qemu/debug.config:CONFIG_SCHED_DEBUG=y
> 
> Indeed - fixed.
> 
> I left out all the defconfigs from the patches, because there's a lot
> of them (~79 reference CONFIG_SCHED_DEBUG ...) and they get refreshed
> naturally in any case.
> 
>> Also ran unixbench and hackbench on 80 CPU system (1NUMA) with and
>> without CONFIG_SCHED_DEBUG. hackbench numbers are almost the same.
>>
>> for unixbench, process creation/Context Switching show 1-2%
>> improvement with CONFIG_SCHED_DEBUG=n
> 
> Thank you for the testing! I'll add:
> 
>    Tested-by: Shrikanth Hegde <sshegde@...ux.ibm.com>
> 
> to the series if you don't mind.

It was minimal testing. If that suffices i am okay with the tag.

> 
> And irrespectively of this series we should probably look at that 1-2%
> overhead in unixbench context switching overhead, maybe there's a few
> low hanging fruits in the debug code.
> 
> 	Ingo

ok. Let me see perf record and see what shows up.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ