----- Original Message -----
> From: "Li Wang" <liw...@redhat.com>
> To: "Jan Stancek" <jstan...@redhat.com>
> Cc: ltp-list@lists.sourceforge.net
> Sent: Tuesday, 6 January, 2015 3:07:16 PM
> Subject: Re: [LTP] [PATCH] mem/hugeshmat: new case for hugepage leak
> inspection
>
> > I'm assuming that both absolute address and sleep is not necessary.
> > I think I'll take some recent kernel, revert that patch and try to
> > reproduce
> > the failure.
>
> Hi Jan,
>
> I just tried kernel-3.10.0+ without the fixed patch, and I hit a CPU stuck
> issue
> with absolute address and sleep(3).
I tried the same with 2.6.18-92.el5. When I revert the patch I can reproduce
the leak.
sleep(3) doesn't seem to have any effect, I think we can safely remove it.
Attaching at BOUNDARY however seems necessary. As soon as I change shmat to use
"NULL",
the leak no longer happens, I'm not sure why that is.
+ if (huge_total != hugepages || huge_free != hugepages)
This condition in setup() seems to strict. I think we don't need all hugepages
to be free when test starts.
Regards,
Jan
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
