| 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
| ||
|
Date: Fri, 10 Oct 2008 11:15:11 +0200 From: Ingo Molnar <mingo@...e.hu> To: Evgeniy Polyakov <s0mbre@...rvice.net.ru> Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, David Miller <davem@...emloft.net>, Mike Galbraith <efault@....de> Subject: Re: [tbench regression fixes]: digging out smelly deadmen. hi Evgeniy, * Evgeniy Polyakov <s0mbre@...rvice.net.ru> wrote: > Hi Peter. > > I've enabled kernel hacking option and scheduler debugging and turned > off hrticks and performance jumped to 382 MB/s: > > vanilla 27: 347.222 > no TSO/GSO: 357.331 > no hrticks: 382.983 > > I use tsc clocksource, also available acpi_pm and jiffies, > with acpi_pm performance is even lower (I stopped test after it dropped > below 340 MB/s mark), jiffies do not work at all, looks like sockets > stuck in time_wait state when this clock source is used, although that > may be some different issue. > > So I think hrticks are guilty, but still not as good as .25 tree without > mentioned changes (455 MB/s) and .24 (475 MB/s). i'm glad that you are looking into this! That is an SMP box, right? If yes then could you try this sched-domains tuning utility i have written yesterday (incidentally): http://redhat.com/~mingo/cfs-scheduler/tune-sched-domains just run it without options to see the current sched-domains options. On a testsystem i have it displays this: # tune-sched-domains usage: tune-sched-domains <val> current val on cpu0/domain0: SD flag: 47 + 1: SD_LOAD_BALANCE: Do load balancing on this domain + 2: SD_BALANCE_NEWIDLE: Balance when about to become idle + 4: SD_BALANCE_EXEC: Balance on exec + 8: SD_BALANCE_FORK: Balance on fork, clone - 16: SD_WAKE_IDLE: Wake to idle CPU on task wakeup + 32: SD_WAKE_AFFINE: Wake task to waking CPU - 64: SD_WAKE_BALANCE: Perform balancing at task wakeup then could you check what effects it has if you turn off SD_BALANCE_NEWIDLE? On my box i did it via: # tune-sched-domains $[47-2] changed /proc/sys/kernel/sched_domain/cpu0/domain0/flags: 47 => 45 SD flag: 45 + 1: SD_LOAD_BALANCE: Do load balancing on this domain - 2: SD_BALANCE_NEWIDLE: Balance when about to become idle + 4: SD_BALANCE_EXEC: Balance on exec + 8: SD_BALANCE_FORK: Balance on fork, clone - 16: SD_WAKE_IDLE: Wake to idle CPU on task wakeup + 32: SD_WAKE_AFFINE: Wake task to waking CPU - 64: SD_WAKE_BALANCE: Perform balancing at task wakeup changed /proc/sys/kernel/sched_domain/cpu0/domain1/flags: 1101 => 45 SD flag: 45 + 1: SD_LOAD_BALANCE: Do load balancing on this domain - 2: SD_BALANCE_NEWIDLE: Balance when about to become idle + 4: SD_BALANCE_EXEC: Balance on exec + 8: SD_BALANCE_FORK: Balance on fork, clone - 16: SD_WAKE_IDLE: Wake to idle CPU on task wakeup + 32: SD_WAKE_AFFINE: Wake task to waking CPU - 64: SD_WAKE_BALANCE: Perform balancing at task wakeup and please, when tuning such scheduler bits, could you run latest tip/master: http://people.redhat.com/mingo/tip.git/README and you need to have CONFIG_SCHED_DEBUG=y enabled for the tuning knobs. so that it's all in sync with upcoming scheduler changes/tunings/fixes. It will also make it much easier for us to apply any fix patches you might send :-) For advanced tuners: you can specify two or more domain flags options as well on the command line - that will be put into domain1/domain2/etc. I usually tune these flags via something like: tune-sched-domains $[1*1+1*2+1*4+1*8+0*16+1*32+1*64] that makes it easy to set/clear each of the flags. Ingo -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists