Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
kostikbel at gmail.com
Tue Jan 31 15:28:37 UTC 2012
On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote:
> ?? 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
I just did checkout + buildworld + buildkernel with -j 10 on UFS with
PCID turned on, everything finished fine. It is up to date HEAD.
sandy% sysctl vm.stats.sys.v_swtch vm.pmap.pcid_save_cnt
I.e. the TLB was not flushed one each second context switch.
Trying the HEAD with the patch is probably easiest way forward.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20120131/d88d9d47/attachment.pgp
More information about the freebsd-current