From owner-freebsd-geom@freebsd.org Thu Apr 20 09:48:47 2017 Return-Path: Delivered-To: freebsd-geom@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 CEC84D4782F for ; Thu, 20 Apr 2017 09:48:47 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 9A736177 for ; Thu, 20 Apr 2017 09:48:47 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-io0-x231.google.com with SMTP id k87so63200348ioi.0 for ; Thu, 20 Apr 2017 02:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sw5ttKX0EIYZzuz0Mo5g3qhsklNWHv2P5CMDHQSPYGg=; b=Usi0OFVzOefW4OswRv6HFLgWtxc839/w0WF0PkdDoZy2KBPE5OZv0A843kvfInnbke WlEg66kR49knhB/NFEYCGab6tWFtu8rq4dNsMfwVJboAn2ozNduHBVpkAM8VdfZVwgaK bkc4VroVzY+eaCkYfo28Vvzb4AAKfMRvbz5Vh9rVFQHx/qfRpnyNm5i3UaT2yhZzZfCI AuOE2V8GazsD6TZf/iHUubirzsTqd2ZvcP2Xb5MNXIp0svPGjNI+gWrr+vwG3ZgMZVsT iGlYeQOyGYugjaK0ZNgeGOILOR0z/SFH2Wye6sfXR2rXP5Kd1tfNYCx++PI8yes2BRIO GHPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sw5ttKX0EIYZzuz0Mo5g3qhsklNWHv2P5CMDHQSPYGg=; b=uZpweOlshCirlEIQGej9OAeejfWU55qWBpqP3Afm/uK2cqyR4tMGgGd7ZY/z2cqxdO mlm9OdgvVllKwaOGXExzxJ0wrFmVNRKeO2hrdOBNIPLq3GMEOr9rmpk7hrC2vw/orxlk ePgyK+Jj3vJXSTrRptUfFaUryVkikcSqeaPkTN8qYYej8MRoMQdijeY/6AOOZBJfxs3a YXkxD+lXUh0DySQG38UHNgq66xmlBCqxh1fKts+5MKIc2qeuHgvJ6aDZhYIsAeGs6oIj mg2vH+JOjGLUcXjfiMSL3CUIkaTVcjx6QBrOvQLvKXpDNF7hUN8mE2WQF7oUDh7VzNY+ TwaA== X-Gm-Message-State: AN3rC/5ojFKaow2QtrwNB22WGfwn9C/LyLa3Yo9SU4WsNSCqXMKyVV+a 7Opr3GC33652WYsPIG5jnwIAHzj/WJqOPRQ= X-Received: by 10.107.138.7 with SMTP id m7mr7848889iod.133.1492681726005; Thu, 20 Apr 2017 02:48:46 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.36.102.193 with HTTP; Thu, 20 Apr 2017 02:48:45 -0700 (PDT) In-Reply-To: References: From: Maxim Sobolev Date: Thu, 20 Apr 2017 02:48:45 -0700 X-Google-Sender-Auth: xWulj8sKC6dOW3WnkM89W9ild5Y Message-ID: Subject: Re: The geom_raid(8) is not load-balancing reads across all available subdisks To: Steven Hartland Cc: Alexander Motin , "M. Warner Losh" , freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 09:48:47 -0000 Steven, thanks for the link but unless I missed something, that benchmark actually talks about spinning disks (2 x HD's and 1 x SSD). My whole point was that in the era when spinning disks are quickly approaching technical obsolescence all those optimizations might easily turn into pessimizations at least for some users and the share of those users is only going to get bigger, not smaller with time. -Max On Tue, Apr 18, 2017 at 8:47 PM, Steven Hartland wrote: > In ZFS we look at the rotational property of the disk as well when > calculating which device to read from, which grave a significant > performance increase. > > See: https://svnweb.freebsd.org/base?view=revision&revision=256956 > > > On Tue, 18 Apr 2017 at 23:17, Maxim Sobolev wrote: > >> Hi, I've got curious as to why running the build on my machine on top of >> the RAID1 volume seems to prefer loading one of the drives for reading. >> Digging into the code I found this: >> >> prio += (G_RAID_SUBDISK_S_ACTIVE - sd->sd_state) << 16; >> /* If disk head is precisely in position - highly prefer >> it. */ >> if (G_RAID_SUBDISK_POS(sd) == bp->bio_offset) >> prio -= 2 * G_RAID_SUBDISK_LOAD_SCALE; >> else >> /* If disk head is close to position - prefer it. */ >> if (ABS(G_RAID_SUBDISK_POS(sd) - bp->bio_offset) < >> G_RAID_SUBDISK_TRACK_SIZE) >> prio -= 1 * G_RAID_SUBDISK_LOAD_SCALE; >> if (prio < bestprio) { >> best = sd; >> bestprio = prio; >> } >> >> Both my drives in RAID are SSDs, so I am wondering if this might be the >> cause. On one hand SSDs can still have some internal buffer to cache the >> nearby data blocks, on the other hand it's really difficult to define how >> far that buffer might extend now and few years from now. On top of that, >> single SATA link is likely to be bottleneck in today's systems (esp with >> Intel XPoint) to get the data into the RAM, so perhaps ripping off this >> optimization for good and just round robin requests between all available >> subdsks would be a better strategy going forward? >> >> -Max >> _______________________________________________ >> freebsd-geom@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-geom >> To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" >> >