On Tue, 27 Mar 2001, Richard Jerrell wrote:
> Oops... I sent out the wrong version of the patch the first time.
> This one has comments, promise. And it has one less bug. :)
Looks good to me (at first glance). Any volunteer to
stress-test this on an SMP machine ?
Rik
--
Virtual memory is
> 1. we take an extra reference on the page, how does that
>affect the test for if the page is shared or not ?
is_page_shared expects us to have our own reference to the page.
> 2. we call delete_from_swap_cache with the pagemap_lru_lock
>held, since this tries to grab the
On Tue, 27 Mar 2001, Richard Jerrell wrote:
>
> Instead of removing the swap cache page at process exit and possibly
> expending time doing disk IO as you have pointed out, we check during
> refill_inactive_scan and page_launder for a page that is
I think this patch looks pretty good. However,
On Tue, 27 Mar 2001, Richard Jerrell wrote:
> Instead of removing the swap cache page at process exit and possibly
> expending time doing disk IO as you have pointed out, we check during
> refill_inactive_scan and page_launder for a page that is
Three comments:
1. we take an extra reference on
> fork and exit are very hot paths in the kernel, and this patch can force
> a page cache lookup on a large number of pte which wouldn't be looked
> up before.
True, but I don't know how large of a performance hit the system takes.
> Given that the leak is, as you say, temporary, and that the
Hi,
On Thu, Mar 22, 2001 at 05:21:46PM -0500, Richard Jerrell wrote:
> 2.4.1 has a memory leak (temporary) where anonymous memory pages that have
> been moved into the swap cache will stick around after their vma has been
> unmapped by the owning process. These pages are not free'd in
Hi,
On Thu, Mar 22, 2001 at 05:21:46PM -0500, Richard Jerrell wrote:
2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process. These pages are not free'd in free_pte()
On Tue, 27 Mar 2001, Richard Jerrell wrote:
Instead of removing the swap cache page at process exit and possibly
expending time doing disk IO as you have pointed out, we check during
refill_inactive_scan and page_launder for a page that is
I think this patch looks pretty good. However, I
1. we take an extra reference on the page, how does that
affect the test for if the page is shared or not ?
is_page_shared expects us to have our own reference to the page.
2. we call delete_from_swap_cache with the pagemap_lru_lock
held, since this tries to grab the pagecache_lock we
On Tue, 27 Mar 2001, Richard Jerrell wrote:
Oops... I sent out the wrong version of the patch the first time.
This one has comments, promise. And it has one less bug. :)
Looks good to me (at first glance). Any volunteer to
stress-test this on an SMP machine ?
Rik
--
Virtual memory is
On Fri, 23 Mar 2001, Richard Jerrell wrote:
> > Your idea is nice, but the patch lacks a few things:
> >
> > - SMP locking, what if some other process faults in this page
> > between the atomic_read of the page count and the test later?
>
> It can't happen. free_pte is called with the
> Your idea is nice, but the patch lacks a few things:
>
> - SMP locking, what if some other process faults in this page
> between the atomic_read of the page count and the test later?
It can't happen. free_pte is called with the page_table_lock held in
addition to having the mmap_sem
Your idea is nice, but the patch lacks a few things:
- SMP locking, what if some other process faults in this page
between the atomic_read of the page count and the test later?
It can't happen. free_pte is called with the page_table_lock held in
addition to having the mmap_sem downed.
On Fri, 23 Mar 2001, Richard Jerrell wrote:
Your idea is nice, but the patch lacks a few things:
- SMP locking, what if some other process faults in this page
between the atomic_read of the page count and the test later?
It can't happen. free_pte is called with the page_table_lock
On Thu, 22 Mar 2001, Richard Jerrell wrote:
> 2.4.1 has a memory leak (temporary) where anonymous memory pages
> that have been moved into the swap cache will stick around after
> their vma has been unmapped by the owning process.
> free_pte in mm/memory.c has been modified to check to see if
2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process. These pages are not free'd in free_pte()
because they are still referenced by the page cache. In addition, if the
2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process. These pages are not free'd in free_pte()
because they are still referenced by the page cache. In addition, if the
On Thu, 22 Mar 2001, Richard Jerrell wrote:
2.4.1 has a memory leak (temporary) where anonymous memory pages
that have been moved into the swap cache will stick around after
their vma has been unmapped by the owning process.
free_pte in mm/memory.c has been modified to check to see if the
2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process. These pages are not free'd in free_pte()
because they are still referenced by the page cache. In addition, if the
2.4.1 has a memory leak (temporary) where anonymous memory pages that have
been moved into the swap cache will stick around after their vma has been
unmapped by the owning process. These pages are not free'd in free_pte()
because they are still referenced by the page cache. In addition, if the
20 matches
Mail list logo
