Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 20 Nov 2001 16:39:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 20 Nov 2001 16:39:38 -0500 Received: from mailout6-1.nyroc.rr.com ([24.92.226.177]:14519 "EHLO mailout6.nyroc.rr.com") by vger.kernel.org with ESMTP id ; Tue, 20 Nov 2001 16:39:24 -0500 Message-ID: <037701c1720a$159ee9a0$1a01a8c0@allyourbase> From: "Dan Maas" To: "Rik van Riel" Cc: In-Reply-To: Subject: Re: Swap Date: Tue, 20 Nov 2001 16:26:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > I bet they're getting mmap()d, like all mp3 programs seem to do Just a note here - I see much fewer buffer underruns and more consistent read-ahead/drop-behind behavior (i.e. no paging of other programs) when using plain read(), as opposed to mmap(). This is in a video playback program that pumps 3.6MB/sec! MP3 datarates are less than 50KB/sec, so I don't really see why they stand to benefit from mmap()... With mmap() you pay the extra cost of setting up/tearing down the mapping, and the kernel->user copy is virtually insignificant anyway (you already are paying for a single copy plus cache pollution when moving the data from filesystem buffer to sound card DMA buffer, so a second copy isn't a big deal)... Regards, Dan - 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/