From owner-freebsd-arch@FreeBSD.ORG Fri Dec 28 23:23:11 2012 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72923428 for ; Fri, 28 Dec 2012 23:23:11 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by mx1.freebsd.org (Postfix) with ESMTP id 395BF8FC08 for ; Fri, 28 Dec 2012 23:23:11 +0000 (UTC) Received: by mail-da0-f48.google.com with SMTP id k18so4984104dae.21 for ; Fri, 28 Dec 2012 15:23:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:x-x-sender:to:cc:subject:in-reply-to :message-id:references:user-agent:mime-version:content-type :x-gm-message-state; bh=fiHLKz30apwHkRZ9aj8H4MqAobTI+bFO7vpBoctKkTg=; b=DB4jw50fEHSfTrq8mBpfNfwcZo77Py+3zJkwcGsXpVHCRx004LDlZ4OY50HjgSJfsU LojI5VjSfawPn17xuEXJyBO8JwZzrk07m/CJ/Ed0KcdaMd8EpEC7jb6UK4ruA+sD2/Q4 v64P4tM5dqZTrDRUcfKJ/7ERgo0B2BJpUQ9rN6oAz3wM3kb61sNDoe40L9fBDaJEAJOu n8TWHu04NIASOXa3xPBC4X3WgraHnsy+4jPa9DHqNQ7ra3c6iHH2v5LWNpa2HfT83B+7 qBh2QLP8eBr7ZFvL3CBLpxhk3p/0HVrqd3z+njxeFBRWg97x6QPyzHznt1DXH3zyDm1J ZWqA== X-Received: by 10.68.191.200 with SMTP id ha8mr107773295pbc.51.1356736985224; Fri, 28 Dec 2012 15:23:05 -0800 (PST) Received: from rrcs-66-91-135-210.west.biz.rr.com (rrcs-66-91-135-210.west.biz.rr.com. [66.91.135.210]) by mx.google.com with ESMTPS id sk1sm20398596pbc.0.2012.12.28.15.23.03 (version=SSLv3 cipher=OTHER); Fri, 28 Dec 2012 15:23:04 -0800 (PST) Date: Fri, 28 Dec 2012 13:22:48 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Poul-Henning Kamp Subject: Re: Unmapped I/O In-Reply-To: <48513.1356734595@critter.freebsd.dk> Message-ID: References: <20121219135451.GU71906@kib.kiev.ua> <48513.1356734595@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Gm-Message-State: ALoCoQmCJDgbAyjqtYOiQx3LKE4k6yOoC46QW0Dd2PivQcxLMJ5Qu3vaN5nWNI2B+83z4w9QeclX Cc: Konstantin Belousov , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2012 23:23:11 -0000 On Fri, 28 Dec 2012, Poul-Henning Kamp wrote: > -------- > In message , Jeff Roberson writes: > >> 3) I find the NOTMAPPED negative flag awkward grammatically. UNMAPPED >> seems more natural. Or a positive MAPPED flag would be better. Minor >> concern, bikeshedding, etc. > > Given that down the road, MAPPED should be the exceptional case, I > think this should not be a negative option. > >> 4) It would be better to have some wrapper functions around the bio >> transient map and or sf buf handling. I will need it to map unmapped cam >> ccbs in device drivers. We need to come to some agreement on this API. >> There should be a fast page-by-page version and a potentially blocking >> all-at-once linear version. > > Do we have credible relevant use-cases for the "map all linear at > once" case ? > > I think it would be better to leave it out, and force those obscure > (already pessimized) cornercases to deal with page by page, rather > than have them cramp our style WRT to max I/O size. > Well some would require significant stack rewrites. The usb code, for example, assumes linear buffers. So the usb mass storage driver can always run in mapped compat mode. That's not a high performance case. The other place seems to be scsi target code and a few other consumers who actually want to poke at the block data. When we send various scsi commands down like identify and read format etc. we always use malloc'd buffers. For now I think it's safe to leave that assumption in place. The PIO like cases can do page by page pretty easily if we give them a nice API. Thanks, Jeff > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. >