On Thursday, October 05, 2017, Nicolas Pitre wrote:
> Do you have the same amount of free memory once booted in both cases?
Yes, almost exactly the same, so obvious it must be working the same for
both cases. That's enough evidence for me.
Thanks.
Chris
On Thu, 5 Oct 2017, Chris Brandt wrote:
> On Wednesday, October 04, 2017, Nicolas Pitre wrote:
> > Anyway, here's a replacement for patch 4/5 below:
> >
> > - >8
> > Subject: cramfs: add mmap support
> >
> > When cramfs_physmem is used then we have the opportunity to map files
> > directly f
On Wednesday, October 04, 2017, Nicolas Pitre wrote:
> On Wed, 4 Oct 2017, Christoph Hellwig wrote:
>
> > As said in my last mail: look at the VM_MIXEDMAP flag and how it is
> > used by DAX, and you'll get out of the vma splitting business in the
> > fault path.
>
> Alright, it appears to work.
>
On Thu, 5 Oct 2017, Christoph Hellwig wrote:
> On Wed, Oct 04, 2017 at 04:47:52PM -0400, Nicolas Pitre wrote:
> > The only downside so far is the lack of visibility from user space to
> > confirm it actually works as intended. With the vma splitting approach
> > you clearly see what gets directl
On Wed, Oct 04, 2017 at 04:47:52PM -0400, Nicolas Pitre wrote:
> The only downside so far is the lack of visibility from user space to
> confirm it actually works as intended. With the vma splitting approach
> you clearly see what gets directly mapped in /proc/*/maps thanks to
> remap_pfn_range(
On Wed, 4 Oct 2017, Christoph Hellwig wrote:
> As said in my last mail: look at the VM_MIXEDMAP flag and how it is
> used by DAX, and you'll get out of the vma splitting business in the
> fault path.
Alright, it appears to work.
The only downside so far is the lack of visibility from user spac
On Tue, Oct 03, 2017 at 11:40:28AM -0400, Nicolas Pitre wrote:
> I provided that explanation several times by now in my cover letter. And
> separately even to you directly at least once. What else should I do?
You should do the right things instead of stating irrelevant things
in your cover lett
On Tue, 3 Oct 2017, Christoph Hellwig wrote:
> On Tue, Oct 03, 2017 at 11:30:50AM -0400, Nicolas Pitre wrote:
> > Unless you have a better scheme altogether to suggest of course, given
> > the existing constraints.
>
> I still can't understand why this convoluted fault path that finds
> vma, at
On Tue, Oct 03, 2017 at 11:30:50AM -0400, Nicolas Pitre wrote:
> Unless you have a better scheme altogether to suggest of course, given
> the existing constraints.
I still can't understand why this convoluted fault path that finds
vma, attempts with all kinds of races and then tries to update th
On Tue, 3 Oct 2017, Christoph Hellwig wrote:
> On Mon, Oct 02, 2017 at 07:33:29PM -0400, Nicolas Pitre wrote:
> > On Tue, 3 Oct 2017, Richard Weinberger wrote:
> >
> > > On Mon, Oct 2, 2017 at 12:29 AM, Nicolas Pitre
> > > wrote:
> > > > On Sun, 1 Oct 2017, Christoph Hellwig wrote:
> > > >
> >
On Mon, Oct 02, 2017 at 07:33:29PM -0400, Nicolas Pitre wrote:
> On Tue, 3 Oct 2017, Richard Weinberger wrote:
>
> > On Mon, Oct 2, 2017 at 12:29 AM, Nicolas Pitre
> > wrote:
> > > On Sun, 1 Oct 2017, Christoph Hellwig wrote:
> > >
> > >> up_read(&mm->mmap_sem) in the fault path is a still a com
On Tue, 3 Oct 2017, Richard Weinberger wrote:
> On Mon, Oct 2, 2017 at 12:29 AM, Nicolas Pitre
> wrote:
> > On Sun, 1 Oct 2017, Christoph Hellwig wrote:
> >
> >> up_read(&mm->mmap_sem) in the fault path is a still a complete
> >> no-go,
> >>
> >> NAK
> >
> > Care to elaborate?
> >
> > What about
On Mon, Oct 2, 2017 at 12:29 AM, Nicolas Pitre wrote:
> On Sun, 1 Oct 2017, Christoph Hellwig wrote:
>
>> up_read(&mm->mmap_sem) in the fault path is a still a complete
>> no-go,
>>
>> NAK
>
> Care to elaborate?
>
> What about mm/filemap.c:__lock_page_or_retry() then?
As soon you up_read() in the
On Sun, 1 Oct 2017, Christoph Hellwig wrote:
> up_read(&mm->mmap_sem) in the fault path is a still a complete
> no-go,
>
> NAK
Care to elaborate?
What about mm/filemap.c:__lock_page_or_retry() then?
Why the special handling on mm->mmap_sem with VM_FAULT_RETRY?
What are the potential problems
up_read(&mm->mmap_sem) in the fault path is a still a complete
no-go,
NAK
15 matches
Mail list logo