All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kristis Makris <kristis.makris@asu.edu>
To: linux-kernel@vger.kernel.org
Subject: Gracefully killing kswapd, or any kernel thread
Date: Wed, 07 Sep 2005 12:41:08 -0700	[thread overview]
Message-ID: <1126122068.2744.20.camel@syd.mkgnu.net> (raw)

Hello,

I'm trying to kill a kernel thread gracefully, in particular kswapd,
without any success.

The goal is to start another kernel thread that contains updated kswapd
functionality, through a loadable module; no kernel recompilation.

I noticed that kernel threads block SIGKILL. Hence, on module load I'm
running:

task = find_task_by_name("kswapd");
if (task != NULL) {
    spin_lock_irq(&task->sigmask_lock);
    sigdelset(&task->blocked, SIGKILL);
    recalc_sigpending(task);
    spin_unlock_irq(&task->sigmask_lock);
    // Also tried issuing here a: kill_proc(task->pid, SIGKILL, 1);
}

Then from userspace I issue:

# ps aux |grep -i swap
root         4  0.0  0.0     0    0 ?        SW   18:36   0:00 [kswapd]
$ kill -9 4

After the kill is issued, kswapd is taking up 99.9% of CPU time and
remains at a runnable state:
# ps aux |grep -i swap
root         4  0.2  0.0     0    0 ?        RW   18:36   0:02 [kswapd]


Can anyone explain why this is happening ? I've tried this with linux
kernels 2.2.19 and 2.4.27 (with patch kdb-4.3). What is the proper way
of gracefully killing a kernel thread launched from the original kernel
image (not a module) in kernels < 2.6 (ie. without the new kernel thread
API that contains the stop_kthread call documented in
http://www.scs.ch/~frey/linux/kernelthreads.html)

I've also tried the same with kflushd, kupdate, and keventd in 2.2.19.
When I do issue a "kill -9" for them I see:

# ps aux
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         2  0.0  0.0     0    0 ?        SW   12:18   0:00 [kflushd]
root         3  1.5  0.0     0    0 ?        RW   12:18   0:16 [kupdate]
root         5  0.0  0.0     0    0 ?        SW   12:18   0:00 [keventd]

All 3 kernel threads remain in the process list. kupdate also appears to
be in a running state consuming 99.9% of the CPU when killed. What's so
special about kupdate and kswapd that makes them stay at a running
state, and why do all kernel threads seem unkillable?

Thanks,
Kristis


             reply	other threads:[~2005-09-07 19:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-07 19:41 Kristis Makris [this message]
2005-09-07 20:08 ` Gracefully killing kswapd, or any kernel thread linux-os (Dick Johnson)
2005-09-07 21:07   ` [ham] " Kristis Makris
2005-09-07 22:31     ` Kyle Moffett
2005-09-07 22:36     ` linux-os (Dick Johnson)
2005-09-09 18:51       ` Kristis Makris
2005-09-09 19:20         ` linux-os (Dick Johnson)
2005-09-09 22:20           ` Kristis Makris

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=1126122068.2744.20.camel@syd.mkgnu.net \
    --to=kristis.makris@asu.edu \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.