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: Tue, 30 Jan 2007 18:29:40 -0600 From: Maynard Johnson <maynardj@...ibm.com> To: Benjamin Herrenschmidt <benh@...nel.crashing.org> CC: linuxppc-dev@...abs.org, oprofile-list@...ts.sourceforge.net, cbe-oss-dev@...abs.org, Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org Subject: Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profiling Cell BE SPUs -- update Benjamin Herrenschmidt wrote: >>I've given this some more thought, and I'm coming to the conclusion that >>a pure array-based implementation for holding cached_info (getting rid >>of the lists) would work well for the vast majority of cases in which >>OProfile will be used. Yes, it is true that the mapping of an SPU >>context to a phsyical spu-numbered array location cannot be guaranteed >>to stay valid, and that's why I discard the cached_info at that array >>location when the SPU task is switched out. Yes, it would be terribly >>inefficient if the same SPU task gets switched back in later and we >>would have to recreate the cached_info. However, I contend that >>OProfile users are interested in profiling one application at a time. >>They are not going to want to muddy the waters with multiple SPU apps >>running at the same time. I can't think of any reason why someone would >>conscisouly choose to do that. >> >>Any thoughts from the general community, especially OProfile users? > > > Well, it's my understanding that quite a few typical usage scenario > involve different tasks running on different SPUs passing each other > data around. That shouldn't be a problem. I would consider this to be "one large application" consisting of multiple SPU binaries running simultaneously. Such a scenario can be handled with no negative performance impact using a simple 16 element array of cached_info objects -- as long as there isn't (much) SPU task switching being done. -Maynard > > Ben. > > - 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