Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?

在 2012年1月31日 上午12:43，Kostik Belousov <kostikbel_at_gmail.com> 写道：
> On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote:
>> ?? 2012??1??30?? ????2:36??Kostik Belousov <kostikbel_at_gmail.com> ??????
>> > On Mon, Jan 30, 2012 at 10:15:51AM +0800, Paul Ambrose wrote:
>> >> I have two boxes, one is  AMD Athlon 610e 2.4G with FreeBSD-current
>> >> patched with pcid.2.patch? It works well without other issue and it
>> >> seem the pcid patch
>> >> does not affect other part of the kernel. The other one is Sandy
>> > Athlons do not have PCID and probably will never implement it. They use
>> > other tricks to get similar optimizations, transparently to the OS.
>> >
>> Just curious, is this AMD similar optimizations
>>  Address Space Number (ASN) and Global flag
>>                           US Patent 6,604,187.
>> http://www.chip-architect.com/news/2003_09_21_Detailed_Architecture_of_AMDs_64bit_Core.html
> This and the same-important next item 'The TLB Flush Filter' is what
> I referred to.
>
>> I did not found anything about ASN in the AMD manual
> It is a transparent optimization, which does not require any OS support.
> Intel PCID is completely different, it shall be explicitely handled by OS.
> It is some consequence of the nested pages support, AFAIU.
>
>>
>> >> Bridge i5-2300 with FreeBSD 9 release patched with pcid.1.patch( the
>> >> pcid.2.patch seems
>> >> dependent on AVX and XSAVE stuffs which is available on -current). But
>> >> it hangs up just in a few minutes. I doubt the nvidia-driver which is
>> >> not recompiled with
>> >> patched kernel is the root, I will check this out  later, but does
>> >> anyone meet similar problem?
>> > There are two many variations compared to the config I did tested.
>> > I do not see anything obvious in the changes between HEAD and stable/9
>> > which could be blamed. Nvidia driver might be bigger suspect, but again,
>> > I am not aware of anything wrong with it.
>> >
>> >>
>> >> I have two question about the pcid.2.patch
>> >
>> > Item 2 is clean, I fixed it.
>> >
>> > For the item 1, I was only able to decipher the proposal to optimize
>> > the global shootdown handler to restore the %cr3 with bit 64 set to not
>> > invalidate current PCID. Is there some more changes ?
>> >
>> yes, that is what I meant. I was wondering using another way that each
>> process has different
>> pcid in each active processor, just as the freebsd mips and powerpc
>> uses. But obviously this way
>> is more friendly to non-pcid  x86  processor.
> Each vmspace (or pmap) has unique PCID with the patch, at least until
> PCID space (12bit) is not exhausted. To really exhaust it, you need 4095
> processes, so it is unlikely but possible event with the current settings.
>
Thank you for your explanation. I just disabled nvidia-driver( not
load it) , and
use "buildworld buildkernel" to test the pcid.1.patch with 9-release,
it seems the box reset before
completing the buildkernel, the attachment is my kernel config, would
you mind try it on
9-release with pcid.1.patch? I will git 10-current a try to see if
there is something wrong with my hardware