Messages in this thread | | | Subject | Re: [RFC, patch] i386: vgetcpu(), take 2 | From | Rohit Seth <> | Date | Thu, 22 Jun 2006 16:10:03 -0700 |
| |
On Fri, 2006-06-23 at 00:14 +0200, Andi Kleen wrote: > > Would sgdt not be sufficient? I agree that we will have to end up > > giving RO access to user for the gdt page. > > I meant exporting the GDT page >
Yes indeed. That shouldn't be an issue though.
> > I agree that we should not overload a single call (though cpu, package > > and node numbers do belong in one category IMO). We can have multiple > > calls if that is required as long as there is an efficient mechanism to > > provide that information. > > The current mechanism doesn't scale to much more calls, but I guess > i'll have to do a vDSO sooner or later. > > > Why maintain that extra logic in user space when kernel can easily give > > that information. > > It already does. >
I'm missing your point here. How and where?
> > > I've been pondering to put some more information about that > > > in the ELF aux vector, but exporting might work too. I suppose > > > exporting would require the vDSO first to give a sane interface. > > > > > Can you please tell me what more information you are thinking of putting > > in aux vector? > > One proposal (not fully fleshed out was) number of siblings / sockets / nodes > I don't think bitmaps would work well there (and if someone really needs > those they can read cpuinfo again) >
This is exactly the point, why do that expensive /proc operation when you can do a quick vsyscall and get all of that information. I'm not sure if Aux is the right direction.
> This is mostly for OpenMP and tuning of a few functions (e.g. on AMD > the memory latencies varies with the number of nodes so some functions > can be tuned in different ways based on that) > > > You are absolutely right that the mechanism I'm proposing makes sense > > only if we have more fields AND if any of those fields are dynamically > > changing. But this is a generic mechanism that could be extended to > > share any user visible information in efficient way. Once we have this > > in place then information like whole cpuinfo, percpu interrupts etc. can > > be retrieved easily. > > The problem with exposing too much is that it might be a nightmare > to guarantee a stable ABI for this. At least it would > constrain the kernel internally. Probably less is better here. >
There will be (in all probability) requests to include as much as possible, but I think that should be manageable with sensible API.
> Also I'm still not sure why user space should care about interrupts? > Okay. I just cooked that example for some monitoring process to find out the interrupts /sec on that CPU. But as you mentioned above sibling, sockets, nodes, flags, and even other characteristics like current p-state are all important information that will help applications sitting in user land (even if some of them will be used only couple of times in the life of a process).
Side note: I don't want to delay the vgetcpu call into mainline because of this discussion (as long as there is no cpuid and tcache in that call).
-rohit
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |