On Thu, 2006-06-22 at 01:29 +0200, Andi Kleen wrote:
> On Thursday 22 June 2006 01:18, Rohit Seth wrote:
> > On Thu, 2006-06-22 at 01:05 +0200, Andi Kleen wrote:
> > > On Thursday 22 June 2006 00:59, Rohit Seth wrote:
> >
> > > > I was thinking of storing it is base address part of the descriptor and
> > > > then using the memory load to read it in vsyscall. (Keeping the p bit
> > > > to zero in the descriptor).
> > >
> > > I'm still not sure where and for what you want to use this. In user space
> > > or in kernel space? And what information should be stored in there?
> > >
> >
> > Store the kernel virtual pointer in gdt to access pda in (proposed)
> > vgetcpu in vsyscall.
> > Using this pointer we can easily reach the cpu and
> > node numbers and any other information that is there in pda. For the
> > cpu and node numbers this will get rid of the need to do a serializing
> > operation cpuid.
> >
> > Does it make any sense?
>
> Ok to spell it out (please correct me if I misinterpreted you). You want to:
>
> - Split PDA into kernel part and user exportable part
yes.
> - Export user exportable part to ring 3
yes for vsyscall purposes.
> - Put base address of user exportable part into GDT
> - Access it using that.
>
These are the steps that I'm proposing in vgetcpu:
Read the GDT pointer in vgetcpu code path. This is the base of gdt
table.
Read descriptor #20 from base.
This is the pointer to user visible part of per cpu data structure.
Please let me know if I'm missing something here.
Just a side note, in your vgetcpu patch, would it be better to return
the logical CPU number (as printed in /proc/cpuinfo). Also, I think
applications would be interested in knowing the physical package id for
cores sharing caches.
> I don't think it can work because the GDT only supports 32bit
> base addresses for code/data segments in long mode and you can't put
> a kernel virtual address into 32bit (only user space there)
>
Really not using the GDT descriptor in terms of loading it in any
segment register.
> And you can't get at at the base address anyways because they
> are ignored in long mode (except for fs/gs). For fs/gs you would
> need to save/restore them to reuse them which would be slow.
>
> You can't also just put them into fs/gs because those are
> already reserved for user space.
>
That is the reason I'm not proposing to alter existing fs/gs.
> Also I don't know what other information other than cpu/node
> would be useful, so just using the 20 bits of limit seems plenty to me.
>
physical id (of the package for exmpale) is another useful field. I
would also like to see number of interrupts serviced by this cpu, page
faults etc. But I think that is a separate discussion.
Thanks,
-rohit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]