| 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: Thu, 4 Mar 2010 09:54:04 -0800 From: Stephane Eranian <eranian@...gle.com> To: Peter Zijlstra <peterz@...radead.org> Cc: mingo@...e.hu, linux-kernel@...r.kernel.org, paulus@...ba.org, robert.richter@....com, fweisbec@...il.com Subject: Re: [RFC][PATCH 08/11] perf, x86: Implement simple LBR support On Thu, Mar 4, 2010 at 12:58 AM, Peter Zijlstra <peterz@...radead.org> wrote: > On Wed, 2010-03-03 at 22:57 +0100, Stephane Eranian wrote: >> I don't understand how LBR state is migrated when a per-thread event is moved >> from one CPU to another. It seems LBR is managed per-cpu. >> >> Can you explain this to me? > > It is not, its basically impossible to do given that the TOS doesn't > count more bits than is strictly needed. > I don't get that about the TOS. So you are saying that one context switch out, you drop the current content of LBR. When you are scheduled back in on an another CPU, you grab whatever is there? > Or we should stop supporting cpu and task users at the same time. > Or you should consider LBR as an event which has a constraint that it can only run on one pseudo counter (similar to what you do with BTS). Scheduling would take care of the mutual exclusion. Multiplexing would provide the work-around. -- 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