From patchwork Thu Oct 3 13:27:54 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Akira Hayakawa X-Patchwork-Id: 2982861 X-Patchwork-Delegate: snitzer@redhat.com Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id A2926BFF0B for ; Thu, 3 Oct 2013 13:32:00 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E797420378 for ; Thu, 3 Oct 2013 13:31:55 +0000 (UTC) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by mail.kernel.org (Postfix) with ESMTP id A285E20373 for ; Thu, 3 Oct 2013 13:31:54 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r93DS4OM003655; Thu, 3 Oct 2013 09:28:05 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r93DS3rj024943 for ; Thu, 3 Oct 2013 09:28:03 -0400 Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.19]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r93DS2Af024906; Thu, 3 Oct 2013 09:28:02 -0400 Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r93DS0PO028175; Thu, 3 Oct 2013 09:28:00 -0400 Received: by mail-pa0-f45.google.com with SMTP id rd3so2606645pab.32 for ; Thu, 03 Oct 2013 06:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=60J7OuxzEyiFan62W+dkfi1n0bqaSODV0nxdnaP4uFk=; b=hD5cMKug3vHNMQTvJbdP+gAnWJKShW5u6zjOdroREKyPbyOrs0uDycFocCo3sRVi6p tZUfBSnqnG6ZlZwAv6+FY1+A668epR/KIBvnYG+5SI7yobO/rFWSbk4RaxtCYrak9S/2 8AFLxuNwEgQxaTiGXL5z1u3iA9glvuxQiresEZUOgtUIXZIaPoRIaMX+xin0on8LqHxw aYtBTeY0sg9cAZ3EEBAvOtnmgKPiUnXaayIaBoGlNgCZkMSh/ojZ5K3a88lY2j3LfrdF RYeoibzXfFtlsuV+/CFrZdeVklbvgfq8d1kOJ1o3AGwm6WyD0jsgoq1mwUl+oM++9eeZ B3Dw== X-Received: by 10.66.141.39 with SMTP id rl7mr9592440pab.46.1380806880431; Thu, 03 Oct 2013 06:28:00 -0700 (PDT) Received: from Akira-Hayakawas-MacBook-Pro.local (em117-55-65-133.emobile.ad.jp. [117.55.65.133]) by mx.google.com with ESMTPSA id fk4sm10662165pab.23.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 06:27:59 -0700 (PDT) Message-ID: <524D70DA.8040308@gmail.com> Date: Thu, 03 Oct 2013 22:27:54 +0900 From: Akira Hayakawa User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mpatocka@redhat.com References: In-Reply-To: X-RedHat-Spam-Score: 0.299 (BAYES_00, DCC_REPUT_00_12, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_BIG_TO_CC, RCVD_IN_DNSWL_LOW, SPF_PASS) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Scanned-By: MIMEDefang 2.68 on 10.5.110.19 X-loop: dm-devel@redhat.com Cc: devel@driverdev.osuosl.org, thornber@redhat.com, snitzer@redhat.com, cesarb@cesarb.net, gregkh@linuxfoundation.org, david@fromorbit.com, linux-kernel@vger.kernel.org, ruby.wktk@gmail.com, dm-devel@redhat.com, agk@redhat.com, joe@perches.com, akpm@linux-foundation.org, ejt@redhat.com, dan.carpenter@oracle.com, m.chehab@samsung.com Subject: Re: [dm-devel] dm-writeboost testing X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, KHOP_BIG_TO_CC, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi, Mikulas, Thank you for reporting. I am really happy to see this report. First, I respond to the performance problem. I will make time later for investigating the rest and answer. Some deadlock issues are difficult to solve in short time. > I tested dm-writeboost with disk as backing device and ramdisk as cache > device. When I run mkfs.ext4 on the dm-writeboost device, it writes data > to the cache on the first time. However, on next mkfs.ext4 invocations, > dm-writeboost writes data to the disk, not to the cache. > > mkfs.ext4 on raw disk: 1.5s > mkfs.ext4 on dm-cache using raw disk and ramdisk: > 1st time - 0.15s > next time - 0.12s > mkfs.ext4 on dm-writeboost using raw disk and ramdisk: > 1st time - 0.11s > next time - 1.71s, 1.31s, 0.91s, 0.86s, 0.82s > > - there seems to be some error in logic in dm-writeboost that makes it not > cache writes if these writes are already placed in the cache. In > real-world scenarios where the same piece of disk is overwritten over and > over again (for example journal), this could cause performance problems. > > dm-cache doesn't have this problem, if you overwrite the same piece of > data again and again, it goes to the cache device. It is not a bug but should/can be optimized. Below is the cache hit path for writes. writeboost performs very poorly when a partial write hits which then turns `needs_cleanup_perv_cache` to true. Partial write hits is believed to be unlikely so I decided to give up this path to make other likely-paths optimized. I think this is just a tradeoff issue of what to be optimized the most. if (found) { if (unlikely(on_buffer)) { mutex_unlock(&cache->io_lock); update_mb_idx = mb->idx; goto write_on_buffer; } else { u8 dirty_bits = atomic_read_mb_dirtiness(seg, mb); /* * First clean up the previous cache * and migrate the cache if needed. */ bool needs_cleanup_prev_cache = !bio_fullsize || !(dirty_bits == 255); if (unlikely(needs_cleanup_prev_cache)) { wait_for_completion(&seg->flush_done); migrate_mb(cache, seg, mb, dirty_bits, true); } I checked that the mkfs.ext4 writes only in 4KB size so it is not gonna turn the boolean value true for going into the slowpath. Problem: Problem is that it chooses the slowpath even though the bio is full-sized overwrite in the test. The reason is that the dirty bits is sometimes seen as 0 and the suspect is the migration daemon. I guess you created the writeboost device with the default configuration. In that case migration daemon always works and some metadata is cleaned up in background. If you turns both enable_migration_modulator and allow_migrate to 0 before beginning the test to stop migration at all it never goes into the slowpath with the test. Solution: Changing the code to avoid going into the slowpath when the dirty bits is zero will solve this problem. And done. Please pull the latest one from the repo. Thanks, Akira --- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel --- a/Driver/dm-writeboost-target.c +++ b/Driver/dm-writeboost-target.c @@ -688,6 +688,14 @@ static int writeboost_map(struct dm_target *ti, struct bio *bio bool needs_cleanup_prev_cache = !bio_fullsize || !(dirty_bits == 255); + /* + * Migration works in background + * and may have cleaned up the metablock. + * If the metablock is clean we need not to migrate. + */ + if (!dirty_bits) + needs_cleanup_prev_cache = false; + if (unlikely(needs_cleanup_prev_cache)) { wait_for_completion(&seg->flush_done); migrate_mb(cache, seg, mb, dirty_bits, true);