Kernel Newbies archive on
 help / color / Atom feed
From: Rik van Riel <>
To: "Irfan Ullah (울라 이르판)" <>,
	"Ruben Safir" <>,
Subject: Re: Software Prefetching using Machine learning
Date: Thu, 10 Oct 2019 09:22:21 -0400
Message-ID: <> (raw)
In-Reply-To: <>

[-- 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

      parent reply index

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-09  3:37 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 publically 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:

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

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Kernel Newbies archive on

Archives are clonable:
	git clone --mirror kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ \
	public-inbox-index kernelnewbies

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone