Re: Try to modify storeSwapOutAble. :-)

From: Henrik Nordstrom <hno@dont-contact.us>
Date: Sat, 27 Apr 2002 09:52:33 +0200

maer727@sohu.com wrote:

> In storeSwapOutAble, we will do the following checks,
>
> if (e->mem_obj->swapout.sio != NULL)
> return 1;
> if (e->mem_obj->inmem_lo > 0)
> return 0;
>
> I think if swapout.sio is not NUll, then the object is able to
> swap out. inmem_lo > 0 means the head of the object is missing.
> I think missing has two cases.

If swapout.sio is not NULL then the object is currently being swapped
out (has a swapout storeIOState handle open).

> 1. The head of object maybe just simply purged from memory and will not swapped out simply to save memory space.

In which case the above will return 0, as the object cannot be swapped
out (the start/head of the object is missing).

> 2. The head of object has been swapped out. And the rest part of object
> is still in memory.

In which case the above will return 1, as the object is currently being
swapped out, and it is safe to continue swapping the object out. The
routines purging data from the memory object won't purge data needed to
be swapped out.

> I also think whether we can change the check sequence, as the following
>
> if (e->mem_obj->inmem_lo > 0)
> return 0;
> if (e->mem_obj->swapout.sio != NULL)
> return 1;

No, we can't. This would case swapout of objects to stop as soon as the
head of the object has been purged from memory after being swapped out,
and as we always purge the data which has been swapped out on large
objects this would give false negative replies very often.

> I think we can not do this, because inmem_lo > 0 sometimes indicates
> the header part of the object is swapping out and surely the rest part
> can be swapped out. But return 0 means the object can not be swapped
> out. So there is a conflict. So we can not change the check order.

Correct.

Regards
Henrik
Received on Sat Apr 27 2002 - 01:53:00 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:22 MST