From owner-freebsd-current@freebsd.org Wed Jun 14 11:21:20 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAC6CD8B726 for ; Wed, 14 Jun 2017 11:21:20 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 752DA83D26 for ; Wed, 14 Jun 2017 11:21:20 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-qk0-x22d.google.com with SMTP id d14so33679494qkb.1 for ; Wed, 14 Jun 2017 04:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4cVrW5sFn92p529mKvwbvWA4dg+YdlATs82W1gdVge8=; b=tZNJGByiYTN6PmOkXVxKa7gL8gMJN8BEnhSK56bOgn/nB3PZxPW3aEO0SQqNtYTujG sx0A5LtzVILqgjRZus3VSg5cENUF5X/2ziwyJMQ6Nl0QZOudrjZt4LEE0ls4zFKM9FG3 9N8xscB+5BbLqcGOxNh7RrgP7D4cZVmBv/BqtDMGik33P93NQOw29A/jNC2QaLTLk780 qapTLtVORWLV6BzqFF1k6ndgkGwoGLQ/XcGEGZrfLQu45ITDcUi/1yMKtvReBUN3FSrm ZVVPa7zXL3xJ6IGzNgnKcz2i8E+BJJIoyrVLKsHcSTyKrq/U63Mh0baSKax+DlV9EnN1 eqQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4cVrW5sFn92p529mKvwbvWA4dg+YdlATs82W1gdVge8=; b=M8v/OgBV17e/+bYaTIpfB4okDDdSq0/w/c/llooPqC0FkLzsQR5pyaAcBCasZhhnK+ Vpu1cestgl1sCxcpMkpPPIUG14NpUX3x83B+g1N+dFqo0HS8wZqH2AWkexgek+INlvcL 2Ad1BeA5LS1ivyFmSt7kfEoZnPFDSZGBDpXzbku7gZAxnJy4sOVQpxOfYYvxPTB5Zqjq kcGH0udhlTylAnbcrnryYWnVGUXleKLEJBplRbd7yKI7Rh3U1603MbwrRw612V5yPz9r GlyB/kXWqHo6E4Sw91oHgkKcI4XFYo683HjEDt3rB4DniFpWNZhEmWa2DAJwQi2Y/mzX x7xw== X-Gm-Message-State: AKS2vOz4Rfq0xn3IcJo1z0VJLUIfK+XFLZ6U0zKV77iEPgtu162QF3RA ZrNVKnnTWoXkeK4b9B5VWo4VJAuVT9/F X-Received: by 10.55.131.132 with SMTP id f126mr131069qkd.212.1497439279289; Wed, 14 Jun 2017 04:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.93.114 with HTTP; Wed, 14 Jun 2017 04:20:48 -0700 (PDT) In-Reply-To: References: <0100015c6fc1167c-6e139920-60d9-4ce3-9f59-15520276aebb-000000@email.amazonses.com> From: Jia-Shiun Li Date: Wed, 14 Jun 2017 19:20:48 +0800 Message-ID: Subject: Re: Time to increase MAXPHYS? To: "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:21:20 -0000 On Sun, Jun 4, 2017 at 1:33 PM, Warner Losh wrote: > On Sat, Jun 3, 2017 at 2:59 PM, Colin Percival > wrote: > > > On January 24, 1998, in what was later renumbered to SVN r32724, dyson@ > > wrote: > > > Add better support for larger I/O clusters, including larger physical > > > I/O. The support is not mature yet, and some of the underlying > > implementation > > > needs help. However, support does exist for IDE devices now. > > > > and increased MAXPHYS from 64 kB to 128 kB. Is it time to increase it > > again, > > or do we need to wait at least two decades between changes? > > > > This is hurting performance on some systems; in particular, EC2 "io1" > disks > > are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized spinning > > rust) > > disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS) > > recommends > > using a maximum I/O size of 1 MB (and despite NFS not being *physical* > I/O > > it > > seems to still be limited by MAXPHYS). > > > > MAXPHYS is the largest I/O transaction you can push through the system. It > doesn't matter that the I/O is physical or not. The name is a relic from a > time that NFS didn't exist. > Sounds like MAXPHYS usage has grown too widespread than intended to be. Would it be better for specific components to depart from MAXPHYS if they care about performance, and use more specific limit from protocol or hardware spec etc. e.g. MAXDMASIZE, MAX_ATA_IO_SIZE, and maybe some query functions. Having a global max for everything to use just doesn't feel right. If this is the direction to go in the long run, then changing MAXPHYS references to own-defined limitations may be more meaningful than raising it universally. Then I'd propose not to raise it, or people would not be motivated to fix that. A quick grep shows that many references use it as a cap only 'for safety'. -Jia-Shiun