[Q] don't allow tmpfs to page out

[Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Is it possible to disable the tmpfs feature to page out
memory to swap?
I didn't find any mount option or something like that
for it in the documentation.

- --
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9UklFGK1OIvVOP4RAvlyAKC0Aoug0HRSa8zRQuFAH8ufFY1C+wCg0ycG
uMXEYVntwUiiueZloUnizPo=
=t1IM
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[William Stearns]

Good afternoon, Michael,

On Wed, 14 Jul 2004, Michael Buesch wrote:

> Is it possible to disable the tmpfs feature to page out
> memory to swap?
> I didn't find any mount option or something like that
> for it in the documentation.

	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
you want.
	Cheers,
	- Bill

---------------------------------------------------------------------------
	"Heisenberg _may_ have slept here."
(Courtesy of Rick Stevens <rstevens@vitalstream.com>)
--------------------------------------------------------------------------
William Stearns (wstearns@pobox.com).  Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at:   http://www.stearns.org
--------------------------------------------------------------------------

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting William Stearns <wstearns@pobox.com>:
> Good afternoon, Michael,

Hi William,

> 	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
> you want.

No, since a regular ramdisk is static in size.

> 	Cheers,
> 	- Bill

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9VZvFGK1OIvVOP4RAku8AJ92P7fjMBBAkf36vKTlYQvH1XluzQCfQ573
LQyLzVpA5o5UfAH/3G2Aq3s=
=jzzh
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

On Wed, 2004-07-14 at 17:51, Michael Buesch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Quoting William Stearns <wstearns@pobox.com>:
> > Good afternoon, Michael,
> 
> Hi William,
> 
> > 	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
> > you want.
> 
> No, since a regular ramdisk is static in size.

which is why there is ramfs .. :)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Arjan van de Ven <arjanv@redhat.com>:
> On Wed, 2004-07-14 at 17:51, Michael Buesch wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Quoting William Stearns <wstearns@pobox.com>:
> > > Good afternoon, Michael,
> > 
> > Hi William,
> > 
> > > 	I suspect a regular ramdisk, as opposed to tmpfs, would do what 
> > > you want.
> > 
> > No, since a regular ramdisk is static in size.
> 
> which is why there is ramfs .. :)

In 2.4, too? Can't find it.
What's the CONFIG_* of ramfs?

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9VlGFGK1OIvVOP4RAn3HAJ9fU0KX6FNJDQwn9gVFGKA506eivgCfd28S
zBmNkGBYQd4lmSmUVSzvmGA=
=eejH
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

On Wed, Jul 14, 2004 at 06:03:18PM +0200, Michael Buesch wrote:
> > 
> > which is why there is ramfs .. :)
> 
> In 2.4, too? Can't find it.
> What's the CONFIG_* of ramfs?

CONFIG_RAMFS


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

Quoting Arjan van de Ven <arjanv@redhat.com>:
> On Wed, Jul 14, 2004 at 06:03:18PM +0200, Michael Buesch wrote:
> > >
> > > which is why there is ramfs .. :)
> >
> > In 2.4, too? Can't find it.
> > What's the CONFIG_* of ramfs?
>
> CONFIG_RAMFS

Ok, that's the thing /dev/ram* is about, isn't it?
I already have a /dev/ram mounted somewhere, but it's
not dynamic in size. What am I missing. I'm kind of
confused now. :)

--
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Wed, Jul 14, 2004 at 06:07:08PM +0200, Michael Buesch wrote:
> Quoting Arjan van de Ven <arjanv@redhat.com>:
> > On Wed, Jul 14, 2004 at 06:03:18PM +0200, Michael Buesch wrote:
> > > >
> > > > which is why there is ramfs .. :)
> > >
> > > In 2.4, too? Can't find it.
> > > What's the CONFIG_* of ramfs?
> >
> > CONFIG_RAMFS
> 
> Ok, that's the thing /dev/ram* is about, isn't it?

nope

> I already have a /dev/ram mounted somewhere, but it's
> not dynamic in size. What am I missing. I'm kind of
> confused now. :)

yes you are;

just do 
mount -t ramfs none /mnt/point


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[Michael Buesch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Arjan van de Ven <arjanv@redhat.com>:
> yes you are;
> 
> just do 
> mount -t ramfs none /mnt/point

Oho, didn't know that. thanks. 8-}

- -- 
Regards Michael Buesch  [ http://www.tuxsoft.de.vu ]


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA9VtOFGK1OIvVOP4RAkUVAJ9r+jZNnOrqvgQbUJM0hfPg310aiwCfaayJ
E9kxdYqT+06O4Vbn1xF19SA=
=yABs
-----END PGP SIGNATURE-----

Re: [Q] don't allow tmpfs to page out

[christophe.varoqui]

> 
> just do 
> mount -t ramfs none /mnt/point
> 
Would that be a suitable solution to store callout binaries for daemons like
multipathd that need to work in case of system-disk outage (/bin & swap on SAN
for example) ?

If so, is it possible and/or correct for the daemon to do a private ramfs mount
for this purpose ?

And while I'm at throwing all the questions I have on my mind :
* how can I disable on-demand loading for the daemon ?
* does mlockall() provides all the necessary garanties ?
* what explains the "offset-by-4" between VSZ and RSS I see when running
mlockall'ed daemon ?

Thanks for the educational work :)

regards,
cvaroqui

Re: [Q] don't allow tmpfs to page out

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]


On Thu, Jul 15, 2004 at 09:58:37AM +0200, christophe.varoqui@free.fr wrote:
> > 
> > just do 
> > mount -t ramfs none /mnt/point
> > 
> Would that be a suitable solution to store callout binaries for daemons like
> multipathd that need to work in case of system-disk outage (/bin & swap on SAN
> for example) ?

somewhat, as long as ALL requirements are there, including all libraries ;)

> If so, is it possible and/or correct for the daemon to do a private ramfs mount
> for this purpose ?

sure; namespaces can do a LOT
> 
> And while I'm at throwing all the questions I have on my mind :
> * how can I disable on-demand loading for the daemon ?
> * does mlockall() provides all the necessary garanties ?

mlockall does not guarantee that syscalls you do don't cause memory
allocations, nor does the ramfs approach.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [Q] don't allow tmpfs to page out

[christophe.varoqui]

Selon Arjan van de Ven <arjanv@redhat.com>:

> 
> On Thu, Jul 15, 2004 at 09:58:37AM +0200, christophe.varoqui@free.fr wrote:
> > > 
> > > just do 
> > > mount -t ramfs none /mnt/point
> > > 
> > Would that be a suitable solution to store callout binaries for daemons
> like
> > multipathd that need to work in case of system-disk outage (/bin & swap on
> SAN
> > for example) ?
> 
> somewhat, as long as ALL requirements are there, including all libraries ;)
> 
ok, sure.
klibc linked static binaries in my case (scsi_id & multipath), so it should be ok.

> > If so, is it possible and/or correct for the daemon to do a private ramfs
> mount
> > for this purpose ?
> 
> sure; namespaces can do a LOT

Somehow "man 2 mount" is not so verbose about that "lot" :)
Can you feed a pointer to a doc explaining how to achieve such privacy ?

> > 
> > And while I'm at throwing all the questions I have on my mind :
> > * how can I disable on-demand loading for the daemon ?
> > * does mlockall() provides all the necessary garanties ?
> 
> mlockall does not guarantee that syscalls you do don't cause memory
> allocations, nor does the ramfs approach.
> 
mmm ... more questions than I had before :)
any hint about how to solve this issue ?

regards,
cvaroqui


--