lkml.org 
[lkml]   [1999]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC]: madvise(2) and mincore(2) in 2.3.26
    From
    Date
    cel@monkey.org (Chuck Lever) writes:

    Hallo Chuck,

    > + */
    > +static long madvise_dontneed(struct vm_area_struct * vma,
    > + unsigned long start, unsigned long end)
    > +{
    > + struct inode * inode = vma->vm_file->f_dentry->d_inode;
    > + struct page * page, **hash;
    > +
    > + start = ((start - vma->vm_start) >> PAGE_CACHE_SHIFT) + vma->vm_pgoff;
    > + end = ((end - vma->vm_start) >> PAGE_CACHE_SHIFT) + vma->vm_pgoff;
    > +
    > + while (start < end) {
    > + hash = page_hash(&inode->i_data, start);
    > +
    > + spin_lock(&pagecache_lock);
    > + page = __find_page_nolock(&inode->i_data, start,
    > + *hash);
    > + if (page)
    > + clear_bit(PG_referenced, &page->flags);
    > + spin_unlock(&pagecache_lock);


    What happens when some other thread/process has set the referenced bit?
    shrink_mmap() could throw the data way.
    I think you need at least check for shared pages here, and make it a nop
    for this case.

    Also is mincore really useful? Either you have the memory locked and
    then then you know that it is in core, or you haven't, then everything
    is possible. I cannot imagine a useful application for it.

    The rest looks very nice.

    -Andi

    --
    This is like TV. I don't like TV.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.024 / U:0.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site