ram/swap

ram/swap

Post by Leander Seig » Tue, 29 Jan 2002 05:37:02



Hello,

my program holds a realy large linked list (a few
100MBytes).
one of my threads always adds members to that
list and one other thread reads them on the other
end and plays the data on the soundcard.
everything is fine but sometimes (when the hdd gets
realy busy) small delays appear (clicks in the sound).

to avoid this i tried to mlock() the next few members
to be played but it seems that these calls need
more time than ignoring if that data is in the
ram or on the harddisc.
btw if i free all mem in a mlocked() page, the
page will become unlocked - is that right?

i also tried to setup up a larger pagesize for the
swap-partition but swapon does not accept it.
is it true that the pagesize can only be 4096 on
x86 systems?

any hints how to force data to be loaded in the ram?
is mlock() the only way to do this?
i'm running linux

thanks
leander

 
 
 

ram/swap

Post by David Konerding, Ph. » Tue, 29 Jan 2002 05:46:49



> Hello,

> my program holds a realy large linked list (a few
> 100MBytes).
> one of my threads always adds members to that
> list and one other thread reads them on the other
> end and plays the data on the soundcard.
> everything is fine but sometimes (when the hdd gets
> realy busy) small delays appear (clicks in the sound).

> to avoid this i tried to mlock() the next few members
> to be played but it seems that these calls need
> more time than ignoring if that data is in the
> ram or on the harddisc.
> btw if i free all mem in a mlocked() page, the
> page will become unlocked - is that right?

mlock is a no-op on Linux-- at least it was in the past, I think the
kernel may have been changed recently to amend that, although I don't
really think mlock is the right solution to your problem.

Also, I've noticed on regular linux that under high disk I/O (even with
DMA enabled) it seems that user processes unrelated to the disk I/O can
be unscheduled for quite some time.  I think the realtime linux
patches attempt to fix that, but there are also other patches that
attempt to address interactivity in other ways, such as decreasing the timer
interrupt.

Dave

 
 
 

ram/swap

Post by Juha Laih » Tue, 29 Jan 2002 06:31:28



Quote:>Also, I've noticed on regular linux that under high disk I/O (even with
>DMA enabled) it seems that user processes unrelated to the disk I/O can
>be unscheduled for quite some time.

What might help for that (but probably not for the clicking sound
problem of the OP), is to enable unmasking of interrupts during disk
ISRs. I.e. the "-u" parameter for hdparm. Read the manual page and test
on your hardware - but be careful.
--
Wolf  a.k.a.  Juha Laiho     Espoo, Finland

         PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
 
 
 

ram/swap

Post by Leander Seig » Tue, 29 Jan 2002 17:48:01


it seems that if i issue the mlock() calls from another thread
the performance becomes much better (nearly perfect). so
i think the mlock() is doing something.

i read that if i munlock() some data and there is locked data
left in that page, the page becomes unlocked anyway.
ok, no problem 'cause i do not realy have to munlock() data.
just free()'ing. so if i free() locked data, do you think the page
becomes unlocked even if there is locked data left in the same
page? and.. if i free() _all_ data of a locked page, does that
page become automatically unlocked or do i have to call
munlock() for that page? (hard to determine which data resides
in which page)

thank you
leander

 
 
 

ram/swap

Post by David Konerding, Ph. » Wed, 30 Jan 2002 09:16:14




>>Also, I've noticed on regular linux that under high disk I/O (even with
>>DMA enabled) it seems that user processes unrelated to the disk I/O can
>>be unscheduled for quite some time.

> What might help for that (but probably not for the clicking sound
> problem of the OP), is to enable unmasking of interrupts during disk
> ISRs. I.e. the "-u" parameter for hdparm. Read the manual page and test
> on your hardware - but be careful.

This is with -u 1 enabled.  That does improve it a bit, but I still notice it.

Dave

 
 
 

ram/swap

Post by Lee Sau Da » Tue, 05 Feb 2002 16:48:55


    Leander> i read that if i munlock() some data and there is locked
    Leander> data left in that page, the page becomes unlocked anyway.
    Leander> ok, no problem 'cause i do not realy have to munlock()
    Leander> data.  just free()'ing. so if i free() locked data, do
    Leander> you think the page becomes unlocked even if there is
    Leander> locked data left in the same page?

Are you  sure free()ing the  data will automatically munlock()  it?  I
doubt!

free is  a library call,  offered by libc  (glibc) whereas mlock  is a
system call, offered  by the OS -- Linux.  You can  find this out with
'man'.  free is  free(3) and mlock is mlock(2).   Man page section "3"
is  for library calls,  and section  "2" is  for system  calls.  Since
free() and  mlock() are APIs offered in  different abstraction layers,
they  shouldn't interfere  with one  another.  In  the very  rare case
where such interference  is present, it WILL be  clearly and EXPLICITY
documented.  So,  if there is no documentations  anywhere a reasonable
man can  find that says  that free() implicitly calls  munlock(), then
you shouldn't assume it does.

    Leander>  and.. if i free()
    Leander> _all_ data of a locked page, does that page become
    Leander> automatically unlocked or do i have to call munlock() for
    Leander> that page? (hard to determine which data resides in which
    Leander> page)

It's safer that  you call munlock().  You may just  be lucky that your
code happened to work, with  this particular combination of OS, glibc,
your code as will as on this particularly lucky year.

In a  well-designed API (which is  the case in Linux  and libc), every
function  that allocates  resources has  a (or  several) corresponding
functions that  deallocate them,  even if  it is just  a no-op  in the
current    implementation.    (This    could    change   in    another
implementation!)  As a good  programming habit (esp.  with C/C++), you
should make sure such allocation  and deallocations are done in pairs,
preferable within  the same function,  or between a pair  of functions
whose  names are  easily guessed  from one  another.  e.g.   if  you a
malloc()  in  your  own  function  go_to_sleep(), you  should  have  a
corresponding (i.e.  manipulating the  same piece of memory area) call
to free() in another  function wake_up().  That makes code development
and   maintenance    much   easier,   and   less    likely   to   have
OS/library-dependent bugs.  Apply this  philosophy to your mlock() and
munlock().

--


Home page: http://www.informatik.uni-freiburg.de/~danlee

 
 
 

ram/swap

Post by Leander Seig » Wed, 06 Feb 2002 02:59:28



>  so if i free() locked data, do
>     Leander> you think the page becomes unlocked even if there is
>     Leander> locked data left in the same page?

> Are you  sure free()ing the  data will automatically munlock()  it?  I
> doubt

that was an question !
i've been talking with somebody on #kernelnewbies and he
told me that free()'d pages do not have to be returnd to the kernel...
anyway - i often mlock()'d more pages than my computer has RAM, so
the libc returns the pages to the kernel and they become unlocked, at
least it seems so.

Quote:>  then
> you shouldn't assume it does.

ok, but if i free()'d memory and so that memory is not assigned to my
task anymore, why should that page stay locked ?

Quote:> It's safer that  you call munlock().  You may just  be lucky that your
> code happened to work, with  this particular combination of OS, glibc,
> your code as will as on this particularly lucky year.

right.

Quote:> In a  well-designed API (which is  the case in Linux  and libc), every
> function  that allocates  resources has  a (or  several) corresponding
> functions that  deallocate them,  even if  it is just  a no-op  in the
> current    implementation.

they told me that mlock() is not a no-op

Quote:>  (This    could    change   in    another
> implementation!)  As a good  programming habit (esp.  with C/C++), you
> should make sure such allocation  and deallocations are done in pairs,
> ...  Apply this  philosophy to your mlock() and
> munlock().

yes, but the kernel doesn't !
- let's say struct a and b live in the same page
- i mlock() struct a and b
- later i munlock() struct a
- struct b is munlock()d too, thats bad

the right way would be to determine the page for each struct. that's pretty easy,
they told me how to do it in the irc. but i don't have the log here. i think it
was a
simple ptr&0x0value operation.

regards
Leander

 
 
 

ram/swap

Post by Kasper Dupon » Wed, 06 Feb 2002 06:43:09




> >  so if i free() locked data, do
> >     Leander> you think the page becomes unlocked even if there is
> >     Leander> locked data left in the same page?

> > Are you  sure free()ing the  data will automatically munlock()  it?  I
> > doubt

> that was an question !
> i've been talking with somebody on #kernelnewbies and he
> told me that free()'d pages do not have to be returnd to the kernel...
> anyway - i often mlock()'d more pages than my computer has RAM, so
> the libc returns the pages to the kernel and they become unlocked, at
> least it seems so.

> >  then
> > you shouldn't assume it does.

> ok, but if i free()'d memory and so that memory is not assigned to my
> task anymore, why should that page stay locked ?

A memory range could very well still be mapped in the process after
it has been free()'d. There could be other allocations on the same
page, and even if there isn't it depends on the library. Malloc and
friends are implemented by a library using mmap and similar
functions. The library will not mlock or munlock any pages. But if
the library returns the memory to the OS using munmap or similar it
should get unlocked.

Quote:

> > In a  well-designed API (which is  the case in Linux  and libc), every
> > function  that allocates  resources has  a (or  several) corresponding
> > functions that  deallocate them,  even if  it is just  a no-op  in the
> > current    implementation.

> they told me that mlock() is not a no-op

If mlock() was a no-op it would violate the specification. It
could be unimplemented which could be signaled by not defining
_POSIX_MEMLOCK_RANGE, any code using mlock should actually check
this definition. Another option would be to always return error
on any call of mlock, but that could prevent some programs from
working at all.

Quote:

> >  (This    could    change   in    another
> > implementation!)  As a good  programming habit (esp.  with C/C++), you
> > should make sure such allocation  and deallocations are done in pairs,
> > ...  Apply this  philosophy to your mlock() and
> > munlock().

> yes, but the kernel doesn't !
> - let's say struct a and b live in the same page
> - i mlock() struct a and b
> - later i munlock() struct a
> - struct b is munlock()d too, thats bad

True, if you need to mlock a struct it should not be allocated
using malloc. Allocating the struct with mmap sounds like a
better idea to me.

Quote:

> the right way would be to determine the page for each struct. that's pretty easy,
> they told me how to do it in the irc. but i don't have the log here. i think it
> was a
> simple ptr&0x0value operation.

Of course doing your own bookkeeping would be another option.

Quote:

> regards
> Leander

Why do you need to mlock some memory, how much memory do you
need to mlock? Would mlockall() be an option for you?

--
Kasper Dupont

 
 
 

ram/swap

Post by Leander Seig » Wed, 06 Feb 2002 18:24:28


Quote:> A memory range could very well still be mapped in the process after
> it has been free()'d. There could be other allocations on the same
> page, and even if there isn't it depends on the library. Malloc and
> friends are implemented by a library using mmap and similar
> functions. The library will not mlock or munlock any pages. But if
> the library returns the memory to the OS using munmap or similar it
> should get unlocked.

ok, ic

Quote:> True, if you need to mlock a struct it should not be allocated
> using malloc. Allocating the struct with mmap sounds like a
> better idea to me.

i have got to look at this....

Quote:> Why do you need to mlock some memory, how much memory do you
> need to mlock? Would mlockall() be an option for you?

i'm dealing with a very huge amount of audio data and to prevent
delays on the playback i have to make sure that the next few sound
fragments are not swapped. i think that i do not have the time to
copy that fragments to locked pages...

regards
leander

 
 
 

ram/swap

Post by Leander Seig » Thu, 07 Feb 2002 02:47:28


i forgot, that of course a struct can be situated in more
than one page. even if it is smaller than one page. can
i assume that it is just the next page (+0x1000) ?

regards
leander

 
 
 

1. Performance, physical ram, swap problem

Hi - Using the tool 'top' on a Solaris 7 dual processor with 1GB RAM
running SilverStream (Java App server) the output shows me that on
38MB of Phyiscal Ram is being used while over 500MB of swap is used
(out of 1GIG of swap).  The App server is configured with a min/max
head size of 512MB ram.  This certainly looks like a problem and I
realize that top is not the end all of perforance tools.  However with
such a gross difference in physical vs swap usage it leads me to
believe that something is wrong.  When the server is under load
(SilverStream is being) it starts swapping and the app server does not
consume more physical ram.

I would really like some adive hear.

Thanks - Michael.
last pid:  3425;  load averages:  0.02,  0.02,  0.02                  
              10:02:09
33 processes:  32 sleeping, 1 on cpu
CPU states: 99.7% idle,  0.0% user,  0.2% kernel,  0.1% iowait,  0.0%
swap
Memory: 1024M real, 779M free, 593M swap in use, 529M swap free

2. Yellow Dog

3. >1G RAM, swap, and per-process address space

4. bufmod.h header file

5. Freeing RAM/swap memory.

6. SPARCprinter hanging

7. use un-cachable RAM as swap on RAM drive

8. Help with Virtual "name" Servers?

9. swap -s and swap -l: disk reserved and RAM reserved

10. Solaris 2.5.1 swap exhausted, but lots of ram left!

11. Settings to use RAM before using SWAP space?

12. I got 16MB of Ram. Swap space, too?

13. 512 DDR Ram - how much swap?