* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-08-02 15:02:25]:

quoted text
> +/*
> + * Because updateing swap_map[] can make not-saved-status-change,
> + * we use our own easy allocator.
> + * Please see kernel/power/swap.c, Used swaps are recorded into
> + * RB-tree.
> + */
> +swp_entry_t get_swap_for_hibernation(int type)
> +{
> +	pgoff_t off;
> +	swp_entry_t val = {0};
> +	struct swap_info_struct *si;
> +
> +	spin_lock(&swap_lock);
> +	/*
> +	 * Once hibernation starts to use swap, we freeze swap_map[]. Otherwise,
> +	 * saved swap_map[] image to the disk will be an incomplete because it's
> +	 * changing without synchronization with hibernation snap shot.
> +	 * At resume, we just make swap_for_hibernation=false. We can forget
> +	 * used maps easily.

I don't understand the consequences of this action. Once swap_map is
fixed, we get additional swapping because we need more free memory,
what happens to the swapped out contents, since resume will never see
the changes? How did this work before 2.6.31?

quoted text
> +	 */
> +	if (!swap_for_hibernation)
> +		hibernation_freeze_swap();
> +
> +	si = swap_info[type];
> +	if (!si || !(si->flags & SWP_WRITEOK))
> +		goto done;
> +
> +	for (off = hibernation_offset[type]; off < si->max; ++off) {
> +		if (!si->swap_map[off])
> +			break;

So this is a linear scan for the first free entry, right?

quoted text
> +	}
> +	if (off < si->max) {
> +		val = swp_entry(type, off);
> +		hibernation_offset[type] = off + 1;
> +	}
> +done:
> +	spin_unlock(&swap_lock);
> +	return val;
> +}
> +

-- 
	Three Cheers,
	Balbir
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/