Thread: Hugetables question
I want to implement hugepages for shared memory, to make it transparent I want to do in this fashion: 1. Reserve memory M of size s 2. Try to allocate hugepage memory of as big size as possible (hs), attach at M. 3. Allocate normal shared memory of size hs - s, and attach it at M+hs. This soulution should work for Linux and Windows, and make no difference for usage of such shared memory in application. (...and this actually works) But in sysv_shmem i saw some checking for memory belonging to other (probably failed) processes, because I can't put new header in step 3, i would like to ask if will be suefficient to: 1. Check creator pid by shmctl. 2. Remove checking of shmem magic 3. Or maybe instead of this better will be to split shared memory, header will be stored under one key and it will contain keys to other individually allocated blocks? Ofocourse moving to POSIX may be much more better, but according to commit feast thread it may be impossible. Maybe some other ideas. Regards, Radek
On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote: > I want to implement hugepages for shared memory, to make it transparent I want > to do in this fashion: > 1. Reserve memory M of size s > 2. Try to allocate hugepage memory of as big size as possible (hs), attach at > M. > 3. Allocate normal shared memory of size hs - s, and attach it at M+hs. > This soulution should work for Linux and Windows, and make no difference for > usage of such shared memory in application. At least in Linux they're trying to make hugepages transparent, so I'm wondering if this is going to make a difference for Linux in the long term. As for your other problem, Perhaps you can put the shmem block first, before the hugemem block? Would require some pointer fiddling, but seems doable. Habe a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle
Martijn van Oosterhout <kleptog@svana.org> Sunday 19 of June 2011 12:35:18 > On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote: > > I want to implement hugepages for shared memory, to make it transparent I > > want to do in this fashion: > > 1. Reserve memory M of size s > > 2. Try to allocate hugepage memory of as big size as possible (hs), > > attach at M. > > 3. Allocate normal shared memory of size hs - s, and attach it at M+hs. > > This soulution should work for Linux and Windows, and make no difference > > for usage of such shared memory in application. > > At least in Linux they're trying to make hugepages transparent, so I'm > wondering if this is going to make a difference for Linux in the long > term. > > As for your other problem, Perhaps you can put the shmem block first, > before the hugemem block? Would require some pointer fiddling, but > seems doable. > > Habe a nice day, > > > Patriotism is when love of your own people comes first; nationalism, > > when hate for people other than your own comes first. > > > > - Charles de Gaulle Yes shmem will be transparent in Linux, but in any case, currently is only for anonymous memory, and has some disadvantages over explicit hugepages. Regards, Radek
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sun, Jun 19, 2011 at 11:56:15AM +0200, Rados??aw Smogura wrote:
>> I want to implement hugepages for shared memory, to make it transparent I want
> At least in Linux they're trying to make hugepages transparent, so I'm
> wondering if this is going to make a difference for Linux in the long
> term.
It's already done, at least in Red Hat's kernels, and I would assume
everywhere pretty soon. I see no percentage in our getting involved
in that.
regards, tom lane
On Sun, Jun 19, 2011 at 12:56, Radosław Smogura <rsmogura@softperience.eu> wrote: > I want to implement hugepages for shared memory Hi, Have you read this post by Tom Lane about the performance estimation and a proof-of-concept patch with hugepages? http://archives.postgresql.org/pgsql-hackers/2010-11/msg01842.php It's possible that there was a flaw in his analysis, but his conclusion is that it's not worth it: > And the bottom line is: if there's any performance benefit at all, > it's on the order of 1%. The best result I got was about 3200 TPS > with hugepages, and about 3160 without. The noise in these numbers > is more than 1% though. Regards, Marti
On Wed, 22 Jun 2011 14:24:17 +0300, Marti Raudsepp wrote: > On Sun, Jun 19, 2011 at 12:56, Radosław Smogura > <rsmogura@softperience.eu> wrote: >> I want to implement hugepages for shared memory > > Hi, > > Have you read this post by Tom Lane about the performance estimation > and a proof-of-concept patch with hugepages? > http://archives.postgresql.org/pgsql-hackers/2010-11/msg01842.php > > It's possible that there was a flaw in his analysis, but his > conclusion is that it's not worth it: > >> And the bottom line is: if there's any performance benefit at all, >> it's on the order of 1%. The best result I got was about 3200 TPS >> with hugepages, and about 3160 without. The noise in these numbers >> is more than 1% though. > > Regards, > Marti Actually when I tried to implement hugepages for palloc (I ware unable to write fast and effective mallocator), my resultwas that when I was using normal pages I got small performance degree, but when I was using huge pages this was fasterthen normal build (even with infective mallocator). I know there are some problems with accessing higher memory (when server is more then 8GB), and hugepages may resolve this. I strictly disagree with opinion if there is 1% it's worthless. 1% here, 1% there, and finally You get 10%, but of coursehugepages will work quite well if will be used in code that require many random "jumps". I think this can be reproducedand some not-common case may be found to get performance of about 10% (maybe upload whole table in shared bufferand randomly "peek" records one by one). Regards,Radek
On Wed, Jun 22, 2011 at 02:31:01PM +0200, Rados??aw Smogura wrote: > I strictly disagree with opinion if there is 1% it's worthless. 1% > here, 1% there, and finally You get 10%, but of course hugepages > will work quite well if will be used in code that require many > random "jumps". I think this can be reproduced and some not-common > case may be found to get performance of about 10% (maybe upload > whole table in shared buffer and randomly "peek" records one by > one). I think the point is not that 1% is worthless, but that it hasn't been shown that it is a 1% improvement, becuase the noise is too large. For benefits this small, what you need to is run each test 100 times and check the mean and standard deviation and see whether the improvment is real or not. When the benefit is 10% you only need a handful of runs to prove it, which is why they're accepted easier. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patriotism is when love of your own people comes first; nationalism, > when hate for people other than your own comes first. > - Charles de Gaulle
Martijn van Oosterhout <kleptog@svana.org> Thursday 23 of June 2011 09:10:20 > On Wed, Jun 22, 2011 at 02:31:01PM +0200, Rados??aw Smogura wrote: > > I strictly disagree with opinion if there is 1% it's worthless. 1% > > here, 1% there, and finally You get 10%, but of course hugepages > > will work quite well if will be used in code that require many > > random "jumps". I think this can be reproduced and some not-common > > case may be found to get performance of about 10% (maybe upload > > whole table in shared buffer and randomly "peek" records one by > > one). > > I think the point is not that 1% is worthless, but that it hasn't been > shown that it is a 1% improvement, becuase the noise is too large. > > For benefits this small, what you need to is run each test 100 times > and check the mean and standard deviation and see whether the > improvment is real or not. > > When the benefit is 10% you only need a handful of runs to prove it, > which is why they're accepted easier. > > Have a nice day, > > > Patriotism is when love of your own people comes first; nationalism, > > when hate for people other than your own comes first. > > > > - Charles de Gaulle I think conclusion from this test was "Much more important things are to do, then 1% benefit" - not "1% is worthless". I will try today hugepages, with random peeks. Regards, Radek
On Thu, Jun 23, 2011 at 5:01 AM, Radosław Smogura <rsmogura@softperience.eu> wrote: > I think conclusion from this test was "Much more important things are to do, > then 1% benefit" - not "1% is worthless". > > I will try today hugepages, with random peeks. I think the real conclusion here is "Linux will soon do this for us automatically without us needing to do anything, so pretty soon there will be no possible benefit at all". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company