Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
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. > 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 ? Thank you for looking at the patch. pgpkG36NzMMe1.pgp Description: PGP signature
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月30日 下午2:36，Kostik Belousov 写道： > 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 I did not found anything about ASN in the AMD manual >> 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. > Thank you for looking at the patch. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: > ?? 2012??1??30?? 2:36??Kostik Belousov ?? > > 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. pgpiiEGbdTChh.pgp Description: PGP signature
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 上午12:43，Kostik Belousov 写道： > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: >> ?? 2012??1??30?? 2:36??Kostik Belousov ?? >> > 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 MYKERNEL Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: > ?? 2012??1??31?? 12:43??Kostik Belousov ?? > > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: > >> ?? 2012??1??30?? 2:36??Kostik Belousov ?? > >> > 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
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
在 2012年1月31日 下午11:28，Konstantin Belousov 写道： > On Tue, Jan 31, 2012 at 09:23:50AM +0800, Paul Ambrose wrote: >> ?? 2012??1??31?? 12:43??Kostik Belousov ?? >> > On Mon, Jan 30, 2012 at 07:08:13PM +0800, Paul Ambrose wrote: >> >> ?? 2012??1??30?? 2:36??Kostik Belousov ?? >> >> > 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. Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 box, system panic ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Does anyone try kib's Sandy Bridge PCID patch (pcid.2.patch)?
On Thu, Feb 02, 2012 at 08:46:47AM +0800, Paul Ambrose wrote: > Unfortunately, I try 10-current(HEAD) with pcid.3.patch in my i5-2300 > box, system panic Unfortunately, you did not provided any details of the panic. Panic message and backtrace is the absolute minimum. pgpxg4eyJtcbA.pgp Description: PGP signature
