[me moving to Gmail 'cause yahoo sucks !]
On Fri, 2006-11-17 at 14:12 +0000, moreau francis wrote:
> Peter Zijlstra wrote:
>
> The new object is the one allocated using:
> new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
>
Of course but at this point the choice of the new VMA is already made
by the caller. So in our case do_munmap() decided that B is the new
one as you said. But I still don't see why...
And as I said previously it will end up by calling consecutively:
vma->vm_ops->open(B)
vma->vm_ops->close(B)
> Please read Mel Gorman's book on memory management to gain a better
> understanding.
>
> http://www.phptr.com/bookstore/product.asp?isbn=0131453483&rl=1
thanks for the link, but I don't expect to find out the answer to this
very specific question in it.
Francis
On Fri, 17 Nov 2006, Francis Moreau wrote:
> On Fri, 2006-11-17 at 14:12 +0000, moreau francis wrote:
> > Peter Zijlstra wrote:
> >
> > The new object is the one allocated using:
> > new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
>
> Of course but at this point the choice of the new VMA is already made
> by the caller. So in our case do_munmap() decided that B is the new
> one as you said. But I still don't see why...
split_vma decides which address range will use the newly allocated
vm_area_struct in such a way as to suit its own convenience, and
that of mremap's move_vma. "new" is the name of a variable in
split_vma, you should stop agonizing over it.
>
> And as I said previously it will end up by calling consecutively:
>
> vma->vm_ops->open(B)
> vma->vm_ops->close(B)
You are attaching too much significance to the current address
of the vma which is passed to your driver in open and close.
As mmap.c splits and merges vmas, in response to system calls
unmapping and mapping, those addresses will change.
The important thing is the info contained within the vma: perhaps
your underlying complaint is that your driver is not getting as
much info as it wants about what's happening?
I think (haven't searched) most drivers, if they care at all,
only care about the total number of their vmas: can free
resources when that count goes down to 0.
Hugh
On 11/18/06, Hugh Dickins <[email protected]> wrote:
> On Fri, 17 Nov 2006, Francis Moreau wrote:
> > On Fri, 2006-11-17 at 14:12 +0000, moreau francis wrote:
> > > Peter Zijlstra wrote:
> > >
> > > The new object is the one allocated using:
> > > new = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
> >
> > Of course but at this point the choice of the new VMA is already made
> > by the caller. So in our case do_munmap() decided that B is the new
> > one as you said. But I still don't see why...
>
> split_vma decides which address range will use the newly allocated
> vm_area_struct in such a way as to suit its own convenience, and
again I don't agree. I would say that do_munmap() decides which
address range will use the new allocated vma object. split_vma() get
this information through its parameter named "new_below".
> >
> > And as I said previously it will end up by calling consecutively:
> >
> > vma->vm_ops->open(B)
> > vma->vm_ops->close(B)
>
> You are attaching too much significance to the current address
> of the vma which is passed to your driver in open and close.
> As mmap.c splits and merges vmas, in response to system calls
> unmapping and mapping, those addresses will change.
>
> The important thing is the info contained within the vma: perhaps
> your underlying complaint is that your driver is not getting as
> much info as it wants about what's happening?
>
not really. I'm not writing a real driver. I just try to understand
how vma things work in Linux. Therefore I just wrote a dumb driver
which has modified vma open/close method in order to detect how these
method are called.
I end up to see "open(B), close(B)" sequence when unmapping a part of
the dumb device that I found strange. I think that "open(A') close(B)"
can give more information to the driver and reflect that B is unmapped
and A' is still mapped and becomes the new mapped area.
But it's may be just me...
thanks
Francis
On Mon, 20 Nov 2006, Francis Moreau wrote:
> On 11/18/06, Hugh Dickins <[email protected]> wrote:
> >
> > split_vma decides which address range will use the newly allocated
> > vm_area_struct in such a way as to suit its own convenience, and
>
> again I don't agree. I would say that do_munmap() decides which
> address range will use the new allocated vma object. split_vma() get
> this information through its parameter named "new_below".
Yes, you're right.
Hugh
On Mon, 20 Nov 2006, Francis Moreau wrote:
>
> I end up to see "open(B), close(B)" sequence when unmapping a part of
> the dumb device that I found strange. I think that "open(A') close(B)"
> can give more information to the driver and reflect that B is unmapped
> and A' is still mapped and becomes the new mapped area.
> But it's may be just me...
I think I do now get your point. But your way round doesn't really
reflect what's going on either: the range A' was already open and now
you open it again. Until there's some driver actually needing more
sophisticated treatment, let's just leave it the simple way it is.
Hugh
On 11/20/06, Hugh Dickins <[email protected]> wrote:
> On Mon, 20 Nov 2006, Francis Moreau wrote:
> >
> > I end up to see "open(B), close(B)" sequence when unmapping a part of
> > the dumb device that I found strange. I think that "open(A') close(B)"
> > can give more information to the driver and reflect that B is unmapped
> > and A' is still mapped and becomes the new mapped area.
> > But it's may be just me...
>
> I think I do now get your point. But your way round doesn't really
my fault, I think I wasn't very clear when explaining myself
> reflect what's going on either: the range A' was already open and now
> you open it again. Until there's some driver actually needing more
> sophisticated treatment, let's just leave it the simple way it is.
Yes, I agree that both ways are not satisfacting. Maybe having
vma->resize() method would have been better, I dunno.
Anyways thanks for your answers.
--
Francis