kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: "Irfan Ullah (울라 이르판)" <irfan@dke.khu.ac.kr>,
	"Ruben Safir" <ruben@mrbrklyn.com>,
	valdis.kletnieks@vt.edu
Cc: greg@kroah.com, kernelnewbies@kernelnewbies.org
Subject: Re: Software Prefetching using Machine learning
Date: Thu, 10 Oct 2019 09:22:21 -0400	[thread overview]
Message-ID: <f5a553b8e5e0034f0db96c49ee5f643f8404c392.camel@surriel.com> (raw)
In-Reply-To: <CA+mB8OwebNHa4V7bd0L9yVi5LE+NmQfV3O83KepUQsFUSvCBJQ@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1614 bytes --]

On Thu, 2019-10-10 at 11:10 +0900, Irfan Ullah (울라 이르판) wrote:
> Thank you  for the responses.
> It is not my assignment. Actually, we have initiated a project based
> on the idea "incorporating artificial intelligence in the linux
> kernel to increase its performance". 

That is an interesting idea, but it is worth keeping in
mind that most "kernel performance" is not about how well
the kernel does something, but about how quickly the kernel
lets userland programs do things.

For example, I have done a lot of work on the scheduler
code recently, and the most common thing I see (whenever
I try something wrong) is for total CPU use in the system
to go up. However, the increase in CPU time used is often
in user space, and not in the kernel.

For example, trying out a bad idea might result in 0.2%
more CPU time spent in the kernel, but 2% more CPU time
spent in user space, due to seeing a larger number of
cache misses from user space programs.

When things are done right, enabling a certain kernel
feature might result in some overhead (say 0.3%), which
is almost entirely caused by cache line misses, resulting
in a total system overhead of twice that (0.6%), because
every cache miss in my code results in something else
getting evicted from the cache, and somebody else incurring
a cache miss as well.

In short, if you want to use machine learning to improve
kernel performance, you need to figure out a way to do
that without causing cache misses in any really hot path.

That puts a serious constraint on what you can do.

-- 
All Rights Reversed.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

      parent reply	other threads:[~2019-10-10 13:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09  3:37 Software Prefetching using Machine learning Irfan Ullah (울라 이르판)
2019-10-09  7:44 ` Greg KH
2019-10-09 19:08 ` Valdis Klētnieks
2019-10-10  0:21   ` Ruben Safir
2019-10-10  0:24   ` Ruben Safir
2019-10-10  2:10     ` Irfan Ullah (울라 이르판)
2019-10-10  2:48       ` Irfan Ullah (울라 이르판)
2019-10-10  5:43         ` Valdis Klētnieks
2019-10-10  5:51         ` Kernel development tools (was Re: Software Prefetching using Machine learning) Valdis Klētnieks
2019-10-10  6:21           ` Irfan Ullah (울라 이르판)
2019-10-10  6:40             ` Greg KH
2019-10-10 13:22       ` Rik van Riel [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=f5a553b8e5e0034f0db96c49ee5f643f8404c392.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=greg@kroah.com \
    --cc=irfan@dke.khu.ac.kr \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=ruben@mrbrklyn.com \
    --cc=valdis.kletnieks@vt.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).