nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: flist -- "Killed" -- oom (*not* 1.8 related)


From: Ken Hornstein
Subject: Re: flist -- "Killed" -- oom (*not* 1.8 related)
Date: Fri, 03 Mar 2023 12:47:53 -0500

>while actual bytes of memory on my laptop are semi-precious, addresses
>in the address space are much less so.  here's somebody who uses mmap(2)
>to allocate a huge chunk of address space, and then madvise(2) (a call i
>think i've never used) to have that chunk backed by (lots and lots of)
>zeroes.
>----
>https://robert.ocallahan.org/2016/06/managing-vast-sparse-memory-on-linux.html
>----

While that is interesting, I see some issues:

- MAP_NORESERVE is a Linux-specific feature of mmap(), as far as I can tell.
  I'm not opposed to OS-specific features but we'd need to think about it
  carefully.
- As for if it would help ... well, it depends on what you are doing.
  In the specific case of flist(1), it would probably help because one
  of things folder_read() does is count up the total number of messages
  in a folder (mp->nummsg) and that's what flist uses.  But if you tried
  to use scan(1) on that folder, well ... what scan(1) does is start
  at "lowmsg" and calls does_exist() on every number between "lowmsg"
  and "highmsg" to determine if that message exists.  And does_exist()
  is using the msgstat array to see if a message exists, so you'd be
  reading every single msgstat array member.

The bottom line is nmh (and MH before it) is just not going to perform
well with billion-sized gaps in message numbers and fixing that is going
to be very very hard.

--Ken



reply via email to

[Prev in Thread] Current Thread [Next in Thread]