All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ayhan Aydin <nsd.project.dev@gmail.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: nsd.project.dev@gmail.com
Subject: [RFC PATCH 0/3] Neural Storage Driver - learning page cache prefetcher
Date: Sat, 25 Jul 2026 21:26:25 +0300	[thread overview]
Message-ID: <20260725182628.221603-1-nsd.project.dev@gmail.com> (raw)

Hello,

This RFC introduces NSD (Neural Storage Driver), a learning prefetcher
for the Linux kernel page cache. NSD monitors I/O patterns via a hook
in filemap_read() and prefetches pages using page_cache_sync_readahead().

Background
==========
The kernel existing readahead uses a fixed-window approach that works
well for purely sequential access. NSD builds on this by learning
access patterns at 4KB region granularity using a synaptic Markov chain:

  - Records transitions between file regions
  - Detects sequential strides of arbitrary length
  - Issues page_cache_sync_readahead() for predicted pages
  - Achieves 98% real hit rate on prefetched pages (SSD)

Performance (x86_64, SATA SSD, kernel 7.0.0)
=============================================
  SQLite FTS (4GB table):  -18.8% query time
  Sequential 64K buffered: +22.6% throughput
  Random 4K buffered:      +1.1% (noise)

Read latency:              130us (no regression)

Key Question
============
Is this approach suitable for the Linux readahead infrastructure?
I would like to hear your opinions on the architecture.

The module currently hooks filemap_read() and issues prefetch via
page_cache_sync_readahead(). Would a deeper integration with the
existing ra_state / file_ra_struct be preferred? Should we extend
file_ra_struct to accommodate pattern history, or keep the predictor
as a separate subsystem?

Patch Summary
=============
  1/3: mm/filemap: Add NSD prefetch hook point (+5 lines)
  2/3: nsd: Core prediction engine (fs/nsd/, ~480 lines)
  3/3: Documentation: Add NSD documentation and MAINTAINERS entry

Signed-off-by: Ayhan Aydin <nsd.project.dev@gmail.com>
---


             reply	other threads:[~2026-07-25 18:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25 18:26 Ayhan Aydin [this message]
2026-07-25 18:26 ` [RFC PATCH 1/3] mm/filemap: Add NSD prefetch hook point Ayhan Aydin
2026-07-25 18:26 ` [RFC PATCH 2/3] nsd: Core prediction engine Ayhan Aydin
2026-07-25 18:26 ` [RFC PATCH 3/3] Documentation: Add NSD filesystem documentation Ayhan Aydin

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=20260725182628.221603-1-nsd.project.dev@gmail.com \
    --to=nsd.project.dev@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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.