From: | Radosław Smogura <rsmogura(at)softperience(dot)eu> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hugetables question |
Date: | 2011-06-19 10:46:17 |
Message-ID: | 201106191246.17577.rsmogura@softperience.eu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2011-06-19 10:51:13 | Re: patch for 9.2: enhanced errors |
Previous Message | Martijn van Oosterhout | 2011-06-19 10:35:18 | Re: Hugetables question |