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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 07 Jul 2008 03:29:23 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Miller <davem@...emloft.net>
Cc:	den@...nvz.org, containers@...ts.osdl.org, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/9] selective (per/namespace) flush of rt_cache

David Miller <davem@...emloft.net> writes:

> From: "Denis V. Lunev" <den@...nvz.org>
> Date: Fri, 04 Jul 2008 17:16:00 +0400
>
>> This series of patches implements selective rt cache flushing to make
>> sure that in one namespace we'll not been able to affect the performance
>> of other from the user space.
>
> Applied and pushed out to net-next-2.6, thanks.
>
> Although I wish patch 9 didn't have to be so ugly. :-/ Also, is it
> really the right thing to do if another namespace's RT cache entries
> are in fact chewing up all the slots in a hash chain?  I think
> the replacement garbage collection algorithm should be namespace
> agnostic.

My VM experience agrees.  The requested flushes from inside the namespace
and for namespace exit really should just flush the routes for that namespace.
However for general route caching and expiry I don't see the point of making
the code per namespace, and my gut feel is that is likely to reduce average
case performance at the cost of better isolation between namespaces.

Denis did I read the patches right and you are making all route cache flushes
per namespace?  Including the periodic expiry?

Eric


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ