Computer Old Farts Forum
 help / color / mirror / Atom feed
From: Larry McVoy <lm@mcvoy.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: coff@tuhs.org
Subject: [COFF] Re: Terminology query - 'system process'?
Date: Thu, 14 Dec 2023 15:54:43 -0800	[thread overview]
Message-ID: <20231214235443.GG6732@mcvoy.com> (raw)
In-Reply-To: <20231214232935.802BB18C08F@mercury.lcs.mit.edu>

On Thu, Dec 14, 2023 at 06:29:35PM -0500, Noel Chiappa wrote:
>     > From: Bakul Shah
> 
>     > Now I'd probably call them kernel threads as they don't have a separate
>     > address space.
> 
> Makes sense. One query about stacks, and blocking, there. Do kernel threads,
> in general, have per-thread stacks; so that they can block (and later resume
> exactly where they were when they blocked)?

Yep, threads have stacks, not sure how they could work without them.
Which reminds me of some Solaris insanity.  Back when I was at Sun, they
were threading the VM and I/O system.  The kernel was pretty bloated
and a stack was 2 8K pages.  The I/O people wanted to allocate a kernel
thread *per page* that was being sent to disk/network.  I pointed out
that this means if all of memory wants to head to disk, your dirty page
cache is 1/3 of memory because the other 2/3s were thread stacks.  They
ignored me, implemented it, and it was a miserable failure and they had
to start over.  They just didn't believe in basic math.

> Use of a kernel process probably makes the BSD pageout daemon code fairly
> straightforward, too (well, as straightforward as anything done by Berzerkly
> was :-).

I have immense respect for the BSD pageout daemon code.  When I did UFS
clustering to make I/O go at the platter speed (rather than 1/2 the platter
speed), it caused a big problem because the pageout daemon could not keep
up with UFS, UFS used up page cache much faster than the pageout daemon 
could free pages.

I wrote somewhere around 13 different pageout daemons in an attempt to do
better than the BSD one.  And, in certain cases, I did do better.  All of
them did at least a little better.  But none of them did better in all
cases.  

That BSD code was subtly awesome, I was at the top of my game and couldn't
beat it.  I ended up implementing a "free behind" in UFS, I'd watch the
variable that controlled kicking the pageout code into running, and I'd
start freeing behind when it was getting close to running (but enough 
ahead that the pageout daemon wouldn't wake up).  It's a really gross
hack but it was the best that I could come up with.

--lm

  reply	other threads:[~2023-12-14 23:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 23:29 Noel Chiappa
2023-12-14 23:54 ` Larry McVoy [this message]
2023-12-15  1:15 ` Bakul Shah
2023-12-15 17:51   ` Paul Winalski
2023-12-15 18:08     ` Warner Losh
2023-12-16  2:04     ` Greg 'groggy' Lehey
2023-12-16 19:21       ` Paul Winalski
2023-12-16 19:44         ` Paul Winalski
2023-12-15 13:43 ` Dan Cross
2023-12-19 13:54 ` Derek Fawcus via COFF
  -- strict thread matches above, loose matches on Subject: below --
2023-12-20 20:35 Noel Chiappa
2023-12-20 19:31 Noel Chiappa
2023-12-20 20:29 ` Paul Winalski
2023-12-31  3:51 ` steve jenkin
2023-12-14 21:48 [COFF] " Noel Chiappa
2023-12-14 22:06 ` [COFF] " Bakul Shah
2023-12-14 22:12   ` Warner Losh
2023-12-14 22:09 ` Clem Cole
2023-12-15 14:20   ` Dan Cross
2023-12-15 16:25     ` Warner Losh
2023-12-15 17:13     ` Bakul Shah
2023-12-15  6:24 ` Lars Brinkhoff
2023-12-15 18:30   ` Stuff Received

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231214235443.GG6732@mcvoy.com \
    --to=lm@mcvoy.com \
    --cc=coff@tuhs.org \
    --cc=jnc@mercury.lcs.mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).