Re: [Lhms-devel] Re: [PATCH 2.6.12-rc3 1/8] mm: manual page migration-rc2 -- xfs-extended-attributes-rc2.patch

[Ray Bryant <raybry@engr.sgi.com>]

Paul Jackson wrote:
> Ray wrote:
> 
>>If one were to use madvise() or mbind() to apply the migration
>>policy flags ... then ... it's necessary to reach down to a common subobject,
>>(such as the file struct, address space struct, or inode) and mark
>>that.
> 
> 
> As I wrote Ray offline earlier today (before noticing this thread), I
> suggested considering adding another flag to fcntl(), not madvise/mbind,
> since fcntl() is sometimes used to make changes to the underlying
> in-core inode.
> 
> My rough idea was to have a S_SKIPMIGRATE flag in the in-core
> inode->i_flag's, defaulting to off, which could be set and gotten via
> fcntl on any file descriptor open on that inode.  The value set would
> persist so long as some file held that dentry->inode open, or until
> changed again.  Just before invoking the call to migrate a task, user
> code could examine each named file mapped into the task, and by opening
> each said file and performing the appropriate fcntl(), mark whether or
> not pages from that mapped file should be migrated.
> 

Actually, we need two flags:  S_SKIPMIGRATE, and S_MIGRATE_NON_SHARED.
I personally prefer using mbind() to set these attributes in the
address space object that maps a particular virtual address range,

I guess I don't see the advantage of invoking file system operations
to describe how memory should be dealt with in a migration operation.
So I'd prefer to keep all of the operations in the memory space, hence
mbind().

This makes sense to me since the migration operation is a policy issue,
and mbind() is in the business of setting memory policy.
-- 
Best Regards,
Ray
-----------------------------------------------
                   Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@sgi.com             raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
            so I installed Linux.
-----------------------------------------------
--
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:"aart@kvack.org"> aart@kvack.org </a>