Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Sep 2001 12:03:28 +0000
From:      Vladimir Dozen <vladimir-dozen@mail.ru>
To:        Alfred Perlstein <bright@mu.org>
Cc:        Vladimir Dozen <vladimir-dozen@mail.ru>, Matt Dillon <dillon@earth.backplane.com>, Wilko Bulte <wkb@freebie.xs4all.nl>, hackers@FreeBSD.ORG
Subject:   Re: VM: dynamic swap remapping (patch)
Message-ID:  <20010930120328.A534@eix.do-labs.spb.ru>
In-Reply-To: <20010929175653.Z59854@elvis.mu.org>; from bright@mu.org on Sat, Sep 29, 2001 at 05:56:53PM -0500
References:  <20010929155941.A291@eix.do-labs.spb.ru> <20010929071024.Q59854@elvis.mu.org> <20010929141349.A80876@freebie.xs4all.nl> <200109291653.f8TGrRR37689@earth.backplane.com> <20010929232953.B341@eix.do-labs.spb.ru> <20010929175653.Z59854@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
ehlo.

> My suggestion, (but not my final say, i'm still open to ideas):
> 
>    Implement a memory status signal to notify processes of changes
>    in the relative amount of system memory.
> 
>    When memory reaches a low or high watermark, the signal is
>    broadcast to all running processes.
> 
>    The default disposition will be to ignore the signal.
> 
>    The signal will be named SIGMEMINFO.  (SIGXfoo means
>    'process has exceeded resource foo')

  Agreed. As for SIG_IGN, can anyone tell me -- can I force
  existing application to use my signal handler? For example,
  by preallocating some shared library? If so, there are no
  contras for ignoring signal by default.

>    The signal will pass via the siginfo struct information
>    such that the process can determine if the system has
>    just exceeded the low watermark (danger) or has reclaimed
>    down to the high watermark (enough free memory).

  Passing more info is always better. Agreed.

> a) over allocate swap a bit and set the low watermark carefully.
> b) do the following enhancement:
> 
>      Provide a system whereby you can swap to the filesystem without
>      additional upcalls/syscalls from userspace, basically, provide
>      some means of paging to the filesystem automatically.
> 
>   then, set your lowwater mark to the size of your swap partition,
>   now your system will alert your processes and automatically swap
>   _anyone_ to the filesystem.
> 
> I really think that this would be more flexible and still allow
> you to achieve what you want... What do you think?

  I can't say anything until I'll got detail. Sorry, English is neither
  my native nor used often, so I may easely miss important details, but
  here is my random comments:
  
  Initally, I was trying the same (I think) approach, but there was 
  some problems. Some kernel function refused to work with VM objects 
  of processes differing from curproc. I.e., it could be hard to work 
  with bigproc inside swap daemon; and swap daemon is the only place 
  where we can detect OOM condition; that's why I used signal to transfer
  control to user space, and then back into kernel -- already in another
  process. Another reason to do it -- to make all limits and quota work
  automatically. Also, I did not wanted to make swap daemon busy too long.
  
  Also, what means "over allocate swap a bit"? How to compute the value
  of that bit? At what moment should we preallocate? Should we repeat
  preallocation after getting SIGMEMINFO (himark)?

  Also, you cannot set low mark to size of swap partition. To create
  file-based swap you need some memory (file operations requires it).
  So, low mark should be a bit lower (that's why I raised value of
  nswap_lowat).

  Finally, if you want to over allocate swap for every process in
  system, the whole swap can wind up consisting of only preallocations.
  Resource management is the role of kernel. Any hard reservation
  interfere with that.

-- 
dozen @ home

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010930120328.A534>