Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 10 Oct 2002 06:55:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 10 Oct 2002 06:55:32 -0400 Received: from hermine.idb.hist.no ([158.38.50.15]:61188 "HELO hermine.idb.hist.no") by vger.kernel.org with SMTP id ; Thu, 10 Oct 2002 06:55:32 -0400 Message-ID: <3DA55E0C.24033BB5@aitel.hist.no> Date: Thu, 10 Oct 2002 13:01:32 +0200 From: Helge Hafting X-Mailer: Mozilla 4.76 [no] (X11; U; Linux 2.5.40mm1 i686) X-Accept-Language: no, en, en MIME-Version: 1.0 To: Giuliano Pochini CC: linux-kernel@vger.kernel.org Subject: Re: [PATCH] O_STREAMING - flag for optimal streaming I/O References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1147 Lines: 28 Giuliano Pochini wrote: > Yes, it makes sense, but it's useless or harmful to discard caches > if nobody else needs memory. You just lose data that may be > requested in the future for no reason. Sure, so the ideal is to not drop unconditionally, but make sure that the "finished" O_STREAMING pages are the very first ones to go whenever memory pressure happens. The question then becomes "can you do that, with no more overhead or code complexity than the existing stuff?" It wouldn't necessarily make much difference, because a linux machine is almost always under memory pressure. Free memory is simply filled up with cache till there is no more left. From then on, all requests for memory are handled by throwing something else out of cache or into swap. In that case the streaming pages are evicted quickly anyway, and the ideal case is no different from the implemented case. Helge Hafting - 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/