linux-kernel - Re: [PATCH 3/4] plist: add plist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140506184341.6e12e80a@gandalf.local.home>
Date:	Tue, 6 May 2014 18:43:41 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Dan Streetman <ddstreet@...e.org>
Cc:	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Mel Gorman <mgorman@...e.de>, Michal Hocko <mhocko@...e.cz>,
	Christian Ehrhardt <ehrhardt@...ux.vnet.ibm.com>,
	Rik van Riel <riel@...hat.com>,
	Weijie Yang <weijieut@...il.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Linux-MM <linux-mm@...ck.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 3/4] plist: add plist_rotate

On Tue, 6 May 2014 17:47:16 -0400
Dan Streetman <ddstreet@...e.org> wrote:

> well the specific reason in swap's case is the need to use
> same-priority entries in a round-robin basis, but I don't know if
> plist_round_robin() is very clear.

No, that's not very clear.

> 
> Maybe plist_demote()?  Although demote might imply actually changing priority.

Agreed.

> 
> plist_shuffle()?  That might imply random shuffling though.

Yep.

> 
> plist_readd() or plist_requeue()?  That might make sense since
> technically the function could be replicated by just plist_del() and
> plist_add(), based on the implementation detail that plist_add()
> inserts after all other same-priority entries, instead of before.

plist_requeue() sounds like the best so far.

> 
> Or add priority into the name explicitly, like plist_priority_yield(),
> or plist_priority_rotate(), plist_priority_requeue()?

No, even plist_yield() assumes priority is the same, thus adding
priority to a plist that means "priority list" is rather redundant.

I think its up between plist_yield() and plist_requeue(), where I'm
leaning towards plist_requeue().

Unless others have any better ideas or objections, lets go with
plist_requeue(). I think that's rather self explanatory and it sounds
just like what you said. It's basically an optimized version of
plist_del() followed by a plist_add().

> Ok here's try 3, before I update the patch :)  Does this make sense?
> 
> This is needed by the next patch in this series, which changes swap
> from using regular lists to track its available swap devices
> (partitions or files) to using plists.  Each swap device has a
> priority, and swap allocates pages from devices in priority order,
> filling up the highest priority device first (and then removing it
> from the available list), by allocating a page from the swap device
> that is first in the priority-ordered list.  With regular lists, swap
> was managing the ordering by priority, while with plists the ordering
> is automatically handled.  However, swap requires special handling of
> swap devices with the same priority; pages must be allocated from them
> in round-robin order.  To accomplish this with a plist, this new
> function is used; when a page is allocated from the first swap device
> in the plist, that entry is moved to the end of any same-priority
> entries.  Then the next time a page needs to be allocated, the next
> swap device will be used, and so on.

OK, I read the above a few times and I think I know where my confusion
is coming from. I was thinking that the pages were being added to the
plist. I believe you are saying that the swap devices themselves are
added to the plist, and when the device is empty (no more pages left)
it is removed from the plist. When dealing with memory and swap one
thinks of managing pages. But here we are managing the devices.

Please state clearly at the beginning of your explanation that the swap
devices are being stored in the plist and stay there as long as they
still have pages left to be allocated from. In order to treat swap
devices of the same priority in a round robin fashion, after a device
has pages allocated from it, it needs to be requeued at the end of it's
priority, behind other swap devices of the same priority in order to
make sure the next allocation comes from a different device (of same
priority).

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