Stephane Eranian wrote: > Hello, > > On Thu, Dec 06, 2007 at 05:51:21PM +0100, Petr Tesarik wrote: >> The RSE synchronization will need a TIF_ flag, but all work-to-be-done >> bits are already used, so we'll have to multiplex TIF_NOTIFY_RESUME >> again. >> > > Yes, I knew this was coming. I think it is okay to multiplex on > TIF_NOITFY_RESUME. However, I think it would be cleaner and likely > more efficient to add yet another TIF flags for perfmon instead of > adding the pfm_needs_checking field. That new TIF flag would not have > to be in the low 7 bits. It could be higher because it would not be > checked by the assembly code but rather in do_notify_resume_user(). > The TIF limitation is just in the assembly code. > > Any comments? I'm making a mental note to review this later for optimization. AFAICS fetching the pfm_needs_checking field is not too costly, but of course it's an extra memory reference (and possibly a cache miss). On a related note, I think that we should be able to use all 8 bits for pending work TIF_ bits despite the brain-damaged sign extension in "and imm8", but I don't have the time now to go through all uses of the thread flags in assembly. Not really sure if it's worth adding one TIF_ bit, because we'll pretty certainly need one more bit in the future... Anyway, I'd like to push the changes to ptrace first, because that's currently broken. Kind regards, Petr Tesarik - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |