From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 9 Sep 2001 16:42:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 9 Sep 2001 16:42:19 -0400 Received: from [208.129.208.52] ([208.129.208.52]:56324 "EHLO xmailserver.org") by vger.kernel.org with ESMTP id ; Sun, 9 Sep 2001 16:42:07 -0400 Message-ID: X-Mailer: XFMail 1.5.0 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 09 Sep 2001 13:44:44 -0700 (PDT) From: Davide Libenzi To: Rik van Riel Subject: Re: Purpose of the mm/slab.c changes Cc: torvalds@transmeta.com, Alan Cox , linux-kernel@vger.kernel.org, Andrea Arcangeli , Manfred Spraul Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 09-Sep-2001 Rik van Riel wrote: > On Sun, 9 Sep 2001, Manfred Spraul wrote: > >> > it provides lifo allocations from both partial and unused slabs. >> >> lifo/fifo for unused slabs is obviously superflous - free is >> free, it doesn't matter which free page is used first/last. > > Mind that the L2 cache is often as much as 10 times faster > than RAM, so it would be nice if we had a good chance that > the slab we just allocated would be in L2 cache. Do You see it as a plus ? The new allocated slab will be very likely written ( w/o regard about the old content ) and an L2 mapping will generate invalidate traffic. - Davide