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]
Date:	Thu, 20 Dec 2012 15:21:26 +0400
From:	Glauber Costa <>
To:	Dave Chinner <>
CC:	<>, <>,
	<>, <>
Subject: Re: [PATCH 09/19] list_lru: per-node list infrastructure

On 11/28/2012 03:14 AM, Dave Chinner wrote:
> From: Dave Chinner <>
> Now that we have an LRU list API, we can start to enhance the
> implementation.  This splits the single LRU list into per-node lists
> and locks to enhance scalability. Items are placed on lists
> according to the node the memory belongs to. To make scanning the
> lists efficient, also track whether the per-node lists have entries
> in them in a active nodemask.

I think it is safe to assume that these functions could benefit from
having more metadata available for them when they run.

Let's say for instance that a hypothetical person, for some unknown
reasons, comes with the idea of replicating those lists transparently
per memcg.

In this case, it is very useful to know which memcg drives the current
call. In general, the struct shrink_control already contains a lot of
data that we use to drive the process. Wouldn't it make sense to also
pass shrink_control as data to those lists as well?

The only drawback of this, is that it would tie it to the shrinking
process. I am not sure if this is a concern, but it if is, maybe we
could replace things like :

+static long
+	struct list_lru		*lru,
+	int			nid,
+	list_lru_walk_cb	isolate,
+	void			*cb_arg,
+	long			*nr_to_walk)


+static long
+	struct list_lru		*lru,
+       struct something_like_shrink_control_not_shrink_control *a)

This way we can augment the data available for the interface, for
instance, passing the memcg context, without going patching all the callers.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists