[Xenomai] Switching to secondary mode despite of use of mmap

[Xenomai] Switching to secondary mode despite of use of mmap

[Umair Ali]

Hello,

I am reading a file of size 600 MB using the mmap function and mlockall(). My question is that is it possible that mmap has not loaded whole file in the memory and if the whole file is not loaded then is it changing to secondary mode while reading the file. The size of system heap is 256KB in the menuconfig for the compiling kernel. If the problem, i think, i have is true then how i can load the such big files using mmap. The output of slackspot is attached with this email. My system specs are
Memory 3.1GiB and processor is intel P4 3.2GHz x 2.

Thanks and regards
Ali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: slackspot_output
Type: application/octet-stream
Size: 20870 bytes
Desc: slackspot_output
URL: <http://xenomai.org/pipermail/xenomai/attachments/20151215/81aeb313/attachment.obj>

Re: [Xenomai] Switching to secondary mode despite of use of mmap

[Gilles Chanteperdrix]

On Tue, Dec 15, 2015 at 11:28:02AM +0000, Umair Ali wrote:
> Hello,
> 
> I am reading a file of size 600 MB using the mmap function and
> mlockall(). My question is that is it possible that mmap has not
> loaded whole file in the memory and if the whole file is not
> loaded then is it changing to secondary mode while reading the
> file.

Unless you have not passed MCL_CURRENT | MCL_FUTURE to mlockall or
did not check mlockall return value and mlockall in fact failed, this
is impossible.

>The size of system heap is 256KB in the menuconfig for the
> compiling kernel.

The size of the system heap has nothing to do with mlockall.

> If the problem, i think, i have is true then how
> i can load the such big files using mmap. The output of slackspot
> is attached with this email. My system specs are Memory 3.1GiB and
> processor is intel P4 3.2GHz x 2.

The slackspot trace you show only contains calls to timerfd_create
and socket. Yes, timerfd_create and socket cause a switch to
secondary mode.

-- 
					    Gilles.
https://click-hack.org

Re: [Xenomai] Switching to secondary mode despite of use of mmap

[Umair Ali]

Thanks Gilles for the reply.

>  The slackspot trace you show only contains calls to timerfd_create
and socket. Yes, timerfd_create and socket cause a switch to
secondary mode.

The slackspot output file shows that socket and timerfd_create is called again and again. But i have used these two once and then in the "while loop" timer is read and packet is send. Does it mean that timerfd_create and socket is calling every time once the one loop finish and start other loop until while loop condition is satisfied. Is there any way i can avoid the transition to secondary mode without using timerfd_create and socket. Can i use cobalt kernel timers service direclty in user space. Please guide me thanks.

BR 
Ali
________________________________________
From: Gilles Chanteperdrix [gilles.chanteperdrix@xenomai.org]
Sent: Tuesday, December 15, 2015 3:59 PM
To: Umair Ali
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] Switching to secondary mode despite of use of mmap

On Tue, Dec 15, 2015 at 11:28:02AM +0000, Umair Ali wrote:
> Hello,
>
> I am reading a file of size 600 MB using the mmap function and
> mlockall(). My question is that is it possible that mmap has not
> loaded whole file in the memory and if the whole file is not
> loaded then is it changing to secondary mode while reading the
> file.

Unless you have not passed MCL_CURRENT | MCL_FUTURE to mlockall or
did not check mlockall return value and mlockall in fact failed, this
is impossible.

>The size of system heap is 256KB in the menuconfig for the
> compiling kernel.

The size of the system heap has nothing to do with mlockall.

> If the problem, i think, i have is true then how
> i can load the such big files using mmap. The output of slackspot
> is attached with this email. My system specs are Memory 3.1GiB and
> processor is intel P4 3.2GHz x 2.

The slackspot trace you show only contains calls to timerfd_create
and socket. Yes, timerfd_create and socket cause a switch to
secondary mode.

--
                                            Gilles.
https://click-hack.org

Re: [Xenomai] Switching to secondary mode despite of use of mmap

[Gilles Chanteperdrix]

On Tue, Dec 15, 2015 at 04:03:58PM +0000, Umair Ali wrote:
> Thanks Gilles for the reply.
> 
> >  The slackspot trace you show only contains calls to timerfd_create
> and socket. Yes, timerfd_create and socket cause a switch to
> secondary mode.
> 
> The slackspot output file shows that socket and timerfd_create is
> called again and again. But i have used these two once and then in
> the "while loop" timer is read and packet is send.

>From the look of the trace, the calls to timerfd_create and socket
belong to different processes. So, I would say that the multiple
instances correspond to multiple instances of your program. Have you
not launched the program multiple times?

If that is the case, and you only get in fact two modes switches due
to timerfd_create() and socket(), are you sure you still have a
problem? Are you sure your problem is not simply the jitter?

> Does it mean
> that timerfd_create and socket is calling every time once the one
> loop finish and start other loop until while loop condition is
> satisfied.

I am sorry, I do not really understand this question, but I believe
the above explanation should be sufficient.

> Is there any way i can avoid the transition to
> secondary mode without using timerfd_create and socket.

There should be no problem using timerfd_create and socket. 

> Can i use
> cobalt kernel timers service direclty in user space. Please guide
> me thanks.

No, kernel space timers are used in kernel space, that is why they
are called "kernel-space timers". But a timerfd is a user-space
interface to a kernel-space timer. I believe I already gave you link
on how to use kernel-space timers if you wish to do so.

-- 
					    Gilles.
https://click-hack.org