public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Kondratiev <vladimir.kondratiev@intel.com>
To: root@chaos.analogic.com
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Kernel threads resource leakage
Date: Fri, 15 Aug 2003 00:29:45 +0300	[thread overview]
Message-ID: <3F3BFF49.8090909@intel.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0308141626440.11823@chaos>

Richard,

I forgot to mention that I use gcc 3.3; it _do_ compile the code I 
submitted since it support declarations after statements.
I did actually run tests with the code included in my posting.

About Makefile, it made this way to ensure you use the same flags as for 
kernel. It is kind of style that proposed in 2.6 kernel, adopted for 2.4.

All,

I am sorry for submitting problem before doing complete analysis. It 
reveals that I used to have improperly compiled kernel. I tried on 
another host (2.4.20 with kdb patch, have no plain 2.4.20 handy right 
now), and it works fine without resource leakage.

Regarding need to create lots of kernel threads. Of course, it is 
useless to do it very often, but consider, for example, wireless network 
card, that need to create kernel thread to manage BSS  MAC.  I would not 
get too deeply into details, but it may be situation when you need to 
create new kernel thread, for example, each laptop suspend-resume cycle.

Sure, thousands of cycles may seems too much, but it is a good way to 
check that you have no leakage. For example, in my driver testing, I do 
thousands of insmod/rmmod cycles and stuff like this. This helps to find 
bugs like 100 bytes leakage per 'insmod'.

Anyway, original example is the right way to create and terminate thread 
and may be used as example.

Sorry again for misleading posting.

Vladimir.

Richard B. Johnson wrote:

>I am using a 2.4.20 kernel. I tried your program.
>First, it didn't compile. So I would guess that you
>never tested your test program. I fixed it and I
>made a more readily useful Makefile, etc., so others
>can try it, too. It is attached.
>
>It works. It doesn't eat any resources. I guess that
>the stuff that actually does 'work' in your actual
>driver module is what is consuming resources.
>
>Although making and deleting a number of kernel threads
>is an interesting exercise, I sure hope that you don't
>really do this in a real application. It is very expensive
>to do this. If you need a kernel thread, you should have
>one (or several) that do the work and never exit.
>
>Cheers,
>Dick Johnson
>Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
>            Note 96.31% of all statistics are fiction.
>  
>



      reply	other threads:[~2003-08-14 21:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-14 20:36 Kernel threads resource leakage Richard B. Johnson
2003-08-14 21:29 ` Vladimir Kondratiev [this message]

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=3F3BFF49.8090909@intel.com \
    --to=vladimir.kondratiev@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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