On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: > ?? 2012??1??31?? ????12:43??Kostik Belousov <kostik...@gmail.com> ?????? > > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: > >> ?? 2012??1??30?? ????2:36??Kostik Belousov <kostik...@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 vm.stats.sys.v_swtch: 13743519 vm.pmap.pcid_save_cnt: 7853519 I.e. the TLB was not flushed one each second context switch. Trying the HEAD with the patch is probably easiest way forward.
pgpn1u9lA6atH.pgp
Description: PGP signature
