All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <jglisse@redhat.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org
Subject: [LSF/MM TOPIC] Killing reliance on struct page->mapping
Date: Mon, 29 Jan 2018 19:43:48 -0500	[thread overview]
Message-ID: <20180130004347.GD4526@redhat.com> (raw)

I started a patchset about $TOPIC a while ago, right now i am working on other
thing but i hope to have an RFC for $TOPIC before LSF/MM and thus would like a
slot during common track to talk about it as it impacts FS, BLOCK and MM (i am
assuming their will be common track).

Idea is that mapping (struct address_space) is available in virtualy all the
places where it is needed and that their should be no reasons to depend only on
struct page->mapping field. My patchset basicly add mapping to a bunch of vfs
callback (struct address_space_operations) where it is missing, changing call
site. Then i do an individual patch per filesystem to leverage the new argument
instead on struct page.

I am doing this for a generic page write protection mechanism which generalize
KSM to file back page. They are couple other aspect like struct page->index,
struct page->private which are addressed in similar way. The block layer is
mostly affected because on block device error it needs the page->mapping to
report I/O error.

Maybe we can kill page->mapping altogether as a result of this. However this is
not my motivation at this time.


Sorry for absence of patchset at this time but i wanted to submit the subject
before LSF/MM deadline.

Cheers,
J�r�me

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org
Subject: [LSF/MM TOPIC] Killing reliance on struct page->mapping
Date: Mon, 29 Jan 2018 19:43:48 -0500	[thread overview]
Message-ID: <20180130004347.GD4526@redhat.com> (raw)

I started a patchset about $TOPIC a while ago, right now i am working on other
thing but i hope to have an RFC for $TOPIC before LSF/MM and thus would like a
slot during common track to talk about it as it impacts FS, BLOCK and MM (i am
assuming their will be common track).

Idea is that mapping (struct address_space) is available in virtualy all the
places where it is needed and that their should be no reasons to depend only on
struct page->mapping field. My patchset basicly add mapping to a bunch of vfs
callback (struct address_space_operations) where it is missing, changing call
site. Then i do an individual patch per filesystem to leverage the new argument
instead on struct page.

I am doing this for a generic page write protection mechanism which generalize
KSM to file back page. They are couple other aspect like struct page->index,
struct page->private which are addressed in similar way. The block layer is
mostly affected because on block device error it needs the page->mapping to
report I/O error.

Maybe we can kill page->mapping altogether as a result of this. However this is
not my motivation at this time.


Sorry for absence of patchset at this time but i wanted to submit the subject
before LSF/MM deadline.

Cheers,
J�r�me

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Glisse <jglisse@redhat.com>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	linux-block@vger.kernel.org
Subject: [LSF/MM TOPIC] Killing reliance on struct page->mapping
Date: Mon, 29 Jan 2018 19:43:48 -0500	[thread overview]
Message-ID: <20180130004347.GD4526@redhat.com> (raw)

I started a patchset about $TOPIC a while ago, right now i am working on other
thing but i hope to have an RFC for $TOPIC before LSF/MM and thus would like a
slot during common track to talk about it as it impacts FS, BLOCK and MM (i am
assuming their will be common track).

Idea is that mapping (struct address_space) is available in virtualy all the
places where it is needed and that their should be no reasons to depend only on
struct page->mapping field. My patchset basicly add mapping to a bunch of vfs
callback (struct address_space_operations) where it is missing, changing call
site. Then i do an individual patch per filesystem to leverage the new argument
instead on struct page.

I am doing this for a generic page write protection mechanism which generalize
KSM to file back page. They are couple other aspect like struct page->index,
struct page->private which are addressed in similar way. The block layer is
mostly affected because on block device error it needs the page->mapping to
report I/O error.

Maybe we can kill page->mapping altogether as a result of this. However this is
not my motivation at this time.


Sorry for absence of patchset at this time but i wanted to submit the subject
before LSF/MM deadline.

Cheers,
Jerome

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2018-01-30  0:43 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-30  0:43 Jerome Glisse [this message]
2018-01-30  0:43 ` [LSF/MM TOPIC] Killing reliance on struct page->mapping Jerome Glisse
2018-01-30  0:43 ` Jerome Glisse
2018-01-31 16:56 ` Al Viro
2018-01-31 16:56   ` Al Viro
2018-01-31 17:42   ` [Lsf-pc] " Jerome Glisse
2018-01-31 17:42     ` Jerome Glisse
2018-01-31 17:42     ` Jerome Glisse
2018-01-31 17:55     ` [Lsf-pc] " Al Viro
2018-01-31 17:55       ` Al Viro
2018-01-31 18:13       ` [Lsf-pc] " Jerome Glisse
2018-01-31 18:13         ` Jerome Glisse
2018-01-31 18:13         ` Jerome Glisse
2018-02-01 15:34         ` [Lsf-pc] " Jens Axboe
2018-02-01 15:34           ` Jens Axboe
2018-02-01 15:57           ` Jerome Glisse
2018-02-01 15:57             ` Jerome Glisse
2018-02-01 15:57             ` Jerome Glisse
2018-02-01 16:00             ` Jens Axboe
2018-02-01 16:00               ` Jens Axboe
2018-02-01 16:33               ` Jerome Glisse
2018-02-01 16:33                 ` Jerome Glisse
2018-02-01 16:33                 ` Jerome Glisse
2018-02-01 12:27     ` Kirill A. Shutemov
2018-02-01 12:27       ` Kirill A. Shutemov
2018-02-01 13:22       ` Jerome Glisse
2018-02-01 13:22         ` Jerome Glisse
2018-02-01 13:22         ` Jerome Glisse
2018-01-31 17:09 ` Igor Stoppa
2018-01-31 17:09   ` Igor Stoppa
2018-01-31 17:09   ` Igor Stoppa
2018-01-31 17:48   ` Jerome Glisse
2018-01-31 17:48     ` Jerome Glisse
2018-01-31 17:48     ` Jerome Glisse

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=20180130004347.GD4526@redhat.com \
    --to=jglisse@redhat.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.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.