Re: [discuss] Re: [RFC, patch] i386: vgetcpu(), take 2

[Andi Kleen <ak@suse.de>]

On Friday 23 June 2006 01:10, Rohit Seth wrote:

> > > 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?

In /proc/cpuinfo. 

Suresh and others even put a lot of thought into how to present the information
there.

Or did you just refer to the overhead of writing a /proc parser?
 
> > > > 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.

It's already used for this at least (hwcap etc.) 

vDSO might be better too, but I haven't thought too much about it yet

> 
> > 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, 

Yes but that doesn't mean all these requests make sense and should
be actually followed :)


> but I think that should be manageable with sensible API.

Not sure. Leaner interfaces are really better here.

It's one of the lessons I learned from libnuma - i provide a lot of tools,
but nearly all people are perfectly satisfied with the total basics. So
it's better to start small and only add stuff when there is really a clear
use case.


> 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).

Ok you want faster monitoring applications? Some faster way than 
/proc for some stuff probably makes sense - but I don't think shared
mappings are the right way for it.

There's still a lot of other possibilities for this like relayfs 
or binary /proc files 
 
> Side note: I don't want to delay the vgetcpu call into mainline because
> of this discussion
I'll probably delay it after 2.6.18

> (as long as there is no cpuid and tcache in that 
> call).

What do you not like about tcache? 

-Andi