Messages in this thread | | | Subject | Re: [RFC, patch] i386: vgetcpu(), take 2 | From | Rohit Seth <> | Date | Wed, 21 Jun 2006 17:55:29 -0700 |
| |
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 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/
| |