Messages in this thread | | | From | Andi Kleen <> | Subject | Re: [RFC, patch] i386: vgetcpu(), take 2 | Date | Fri, 23 Jun 2006 00:14:17 +0200 |
| |
> 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
> 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'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 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.
Also I'm still not sure why user space should care about interrupts?
-Andi - 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/
| |