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: Wed, 27 Sep 2006 19:46:00 +0000 From: Pavel Machek <pavel@....cz> To: jeremy@...p.org Cc: akpm@...l.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/6] Per-processor private data areas for i386 Hi! > [ Changes since previous post: > - roll a new set of patches with all updates, based on 2.6.18-mm1 ] > > Implement per-processor data areas for i386. > > This patch implements per-processor data areas by using %gs as the > base segment of the per-processor memory. This has two principle > advantages: > > - It allows very simple direct access to per-processor data by > effectively using an effective address of the form %gs:offset, where > offset is the offset into struct i386_pda. These sequences are faster > and smaller than the current mechanism using current_thread_info(). > > - It also allows per-CPU data to be allocated as each CPU is brought > up, rather than statically allocating it based on the maximum number > of CPUs which could be brought up. > > Performance: > > I've done some simple performance tests on an Intel Core Duo running > at 1GHz (to emphisize any performance delta). The results for the > lmbench null syscall latency test, which should show the most negative > effect from this change, show a ~9ns decline (.237uS -> .245uS). > This corresponds to around 9 CPU cycles, and correlates well with > the addition of the push/load/pop %gs into the hot path. So we have 4% slowdown... > I have not yet measured the effect on other typees of processor or > more complex syscalls (though I would expect the push/pop overhead > would be drowned by longer times spent in the kernel, and mitigated by > actual use of the PDA). > > The size improvements on the kernel text are nice as well: > 2889361 -> 2883936 = 5425 bytes saved ...and 0.2% smaller kernel. I guess you should demonstrate speedup at complex syscalls before wedecide it is worth it...? -- Thanks for all the (sleeping) penguins. - 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/
Powered by blists - more mailing lists