On Mon, Jan 05, 2009 at 11:08:53AM -0800, mehul vora wrote:
> Adam,
>
> I tried that, but gdb receives SIGSEGV immediately after calling
> "munmap"... GDB shows the fault address as a "next to `munmap` jump
> instruction". I took objdump of the image to confirm this.
>
> But i believe, program
Oohh... I think i understood now !!! Thanks a lot for your help Will try
to bring up this
on MIPS and will update you guys asap.
Appreciate your help..
Thanks,
Mehul.
--- On Mon, 1/5/09, Adam Litke wrote:
From: Adam Litke
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: mehu
ed ??
>
> Since libhugetlbfs is a library, it has it's own text and data
> segments (independent of the program). So the library code runs
> uninhibited since only the program segments (not the library segments)
> are unmapped.
>
>
> thanks,
> Mehul.
>
>
any page table / tlbs info ? Is the "constructor"
code in
libhugetlbfs sits under any specific segment other than ".text" which is never
unmapped ??
thanks,
Mehul.
--- On Mon, 1/5/09, Adam Litke wrote:
From: Adam Litke
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: mehu
On Mon, 2009-01-05 at 10:25 -0800, mehul vora wrote:
>
> Adam,
>
> I just commented out printfs, but still program gets a seg fault. I
> have a tight loop after "munmap", so ideally program should never come
> out, but for me program gets a SIGSEGV after first munmap
>
> Could you run your
ubject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: "Nishanth Aravamudan"
Cc: "mehul vora" , libhugetlbfs-devel@lists.sourceforge.net
Date: Monday, January 5, 2009, 12:19 PM
On Mon, 2009-01-05 at 09:07 -0800, Nishanth Aravamudan wrote:
> On 05.01.2009 [06:26:55 -0800
A few thoughts: we don't unmap all segments, only those that need to be
remapped. Not sure if that matters. The only external reference we
resolve between unmapping and mapping is mmap(), which is why we have
that false mmap() call. So, nothing else should access the text segment
between unmap an
On Mon, 2009-01-05 at 09:07 -0800, Nishanth Aravamudan wrote:
> On 05.01.2009 [06:26:55 -0800], mehul vora wrote:
> > Nishanth,
> >
> > I went through "munmap" code and found that core kernel (arch
> > independent) code removes all "vma" references of the passed vaddr and
> > then it calls a
On 05.01.2009 [06:26:55 -0800], mehul vora wrote:
> Nishanth,
>
> I went through "munmap" code and found that core kernel (arch
> independent) code removes all "vma" references of the passed vaddr and
> then it calls arch dependent hooks. MIPS code removes all pagetable
> reference of the pa
om copying
all segments in to hugepages to make this work ?
Thanks,
Mehul.
--- On Wed, 12/31/08, Nishanth Aravamudan wrote:
From: Nishanth Aravamudan
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: "mehul vora"
Cc: libhugetlbfs-devel@lists.sourceforge.net, a...@us.ibm.com
Date: W
, Nishanth Aravamudan wrote:
From: Nishanth Aravamudan
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: "mehul vora"
Cc: libhugetlbfs-devel@lists.sourceforge.net, a...@us.ibm.com
Date: Wednesday, December 31, 2008, 1:01 PM
On 31.12.2008 [07:26:38 -0800], mehul vora wrote:
On 31.12.2008 [07:26:38 -0800], mehul vora wrote:
> Nishanth,
>
> Couple of doubts...
>
> 1) Can't text remapping cause any problem with the "code" being
> executed ? I mean, from code (function - remap_segments() ) it looks
> like "code remaps itself". If any tlb exception comes after "munma
--- On Tue, 12/30/08, Nishanth Aravamudan wrote:
From: Nishanth Aravamudan
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: "mehul vora"
Cc: libhugetlbfs-devel@lists.sourceforge.net, a...@us.ibm.com
Date: Tuesday, December 30, 2008, 11:17 AM
On 29.12.2008 [21:53:03 -0800], mehul vora wrot
... those who knows binary and
those who do not..
--- On Tue, 12/30/08, Nishanth Aravamudan wrote:
From: Nishanth Aravamudan
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: "mehul vora"
Cc: libhugetlbfs-devel@lists.sourceforge.net, a...@us.ibm.com
Date: Tuesday, December 30, 2008
On 29.12.2008 [21:53:03 -0800], mehul vora wrote:
> Nishanth,
>
> Thanks, i will probably migrate to 2.6.27 then.
Well, 2.6.28 is out -- I'd probably go with that, in case there are
kernel fixes even then. Not sure if there were or not, you could check
the changelog.
> Another doubt i had wa
There are only 10 kind of people in the world ... those who knows binary and
those who do not..
--- On Mon, 12/29/08, Nishanth Aravamudan wrote:
From: Nishanth Aravamudan
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: "mehul vora"
Cc: libhugetlbfs-devel@lists.sourceforge.n
On 25.12.2008 [06:01:26 -0800], mehul vora wrote:
> Hi Guys,
>
> Marry X-MAS to you ALL.
>
> I am re-starting the long paused libhugetlb porting for MIPS.
>
> One quick question - Is there any additional driver/kernel
> component to support libhugetlbfs that i may have to port for MIPS ?
Hi Guys,
Marry X-MAS to you ALL.
I am re-starting the long paused libhugetlb porting for MIPS.
One quick question - Is there any additional driver/kernel component to
support libhugetlbfs that i may have to port for MIPS ?
I have already ported the basic hugetlb (except MAP_PRIVATE)
On Wed, 24 Sep 2008, mehul vora wrote:
>
> Hi Eric
>
> I would like to port libhugetlbfs for mips architecture. I have already
> ported hugetlb for MIPS kernel. Do you guys have any porting guide for this ?
> Any pointers on "How to start"
> will be appreciated.
>
>
> Thanks,
> Mehul.
19 matches
Mail list logo
