On Tue 12-02-19 14:09:03, Jiri Kosina wrote:
> On Tue, 12 Feb 2019, Michal Hocko wrote:
>
> > I would go with patch 1 for 5.1. Patches 2 still sounds controversial or
> > incomplete to me.
>
> Is it because of the disagreement what 'non-blocking' really means, or do
> you see something else
On Tue, 12 Feb 2019, Michal Hocko wrote:
> I would go with patch 1 for 5.1. Patches 2 still sounds controversial or
> incomplete to me.
Is it because of the disagreement what 'non-blocking' really means, or do
you see something else missing?
Merging patch just patch 1 withouth patch 2 is
On Tue 12-02-19 04:44:30, Jiri Kosina wrote:
> On Fri, 1 Feb 2019, Vlastimil Babka wrote:
>
> > >> After "mm/mincore: make mincore() more conservative" we sometimes
> > >> restrict the
> > >> information about page cache residency, which we have to do without
> > >> breaking
> > >> existing
On Fri, 1 Feb 2019, Vlastimil Babka wrote:
> >> After "mm/mincore: make mincore() more conservative" we sometimes restrict
> >> the
> >> information about page cache residency, which we have to do without
> >> breaking
> >> existing userspace, if possible. We thus fake the resulting values as
On Fri, 1 Feb 2019, Vlastimil Babka wrote:
> > Well, but rss update will not tell you that the page has been faulted in
> > which is the most interesting part.
>
> Sure, but the patch doesn't add back that capability neither. It allows
> to recognize page being reclaimed, and I argue you can
On 2/1/19 10:11 AM, Michal Hocko wrote:
> On Fri 01-02-19 10:04:23, Vlastimil Babka wrote:
>> The side channel exists anyway as long as process can e.g. check if
>> its rss shrinked, and I doubt we are going to remove that possibility.
>
> Well, but rss update will not tell you that the page has
On Fri 01-02-19 10:04:23, Vlastimil Babka wrote:
> The side channel exists anyway as long as process can e.g. check if
> its rss shrinked, and I doubt we are going to remove that possibility.
Well, but rss update will not tell you that the page has been faulted in
which is the most interesting
On 1/31/19 11:09 AM, Michal Hocko wrote:
> On Wed 30-01-19 13:44:20, Vlastimil Babka wrote:
>> After "mm/mincore: make mincore() more conservative" we sometimes restrict
>> the
>> information about page cache residency, which we have to do without breaking
>> existing userspace, if possible. We
On Wed 30-01-19 13:44:20, Vlastimil Babka wrote:
> After "mm/mincore: make mincore() more conservative" we sometimes restrict the
> information about page cache residency, which we have to do without breaking
> existing userspace, if possible. We thus fake the resulting values as 1, which
> should
After "mm/mincore: make mincore() more conservative" we sometimes restrict the
information about page cache residency, which we have to do without breaking
existing userspace, if possible. We thus fake the resulting values as 1, which
should be safer than faking them as 0, as there might
10 matches
Mail list logo
