From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,SUBJECT_NEEDS_ENCODING, SUBJ_ILLEGAL_CHARS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 50051C433E0 for ; Sat, 20 Jun 2020 09:52:12 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1D7ED23ACA for ; Sat, 20 Jun 2020 09:52:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D7ED23ACA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94) (envelope-from ) id 1jmaAD-0001rN-Rl; Sat, 20 Jun 2020 05:51:53 -0400 Received: from omr1.cc.ipv6.vt.edu ([2607:b400:92:8300:0:c6:2117:b0e] helo=omr1.cc.vt.edu) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1jmaAB-0001rI-RL for Kernelnewbies@kernelnewbies.org; Sat, 20 Jun 2020 05:51:51 -0400 Received: from mr4.cc.vt.edu (inbound.smtp.ipv6.vt.edu [IPv6:2607:b400:92:9:0:9d:8fcb:4116]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id 05K9pp1a000812 for ; Sat, 20 Jun 2020 05:51:51 -0400 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by mr4.cc.vt.edu (8.14.7/8.14.7) with ESMTP id 05K9pk5B003439 for ; Sat, 20 Jun 2020 05:51:51 -0400 Received: by mail-qv1-f71.google.com with SMTP id x16so8751233qvp.19 for ; Sat, 20 Jun 2020 02:51:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=HNevEMZG9sEb7ME6j8GXJCvmuqWrePCUNTI/1dGbenE=; b=WehogfKyPv0H2b4E24GNSK7B9uYjqKYZDs5nkl7JsWy2aXCgVsv6Ra0wFONHI5BeuA bbVpIWcGoQA437+ps102P+Wij9LgZq5zkJndu0SsulnURYn5Okh8U4FSiWv8S1nnO4oh 68v8rcAKGwWz+jQsR0Ei1qx5Rj9456L7PJIQUQtYobm0crUZ0+2o8fXW6ItLmTpnt0kQ 7ILQ1/c2Pjy1ZJQoD9knYntLXVmlwaPZoEee6Y01RhyM22JT+xDB1yOtgz39pAJdNDjq J7M3jrUDG9rILZ+OVXZHiG0ObSe12TsZnphg/heJ944GwG3aV+mJgE2y5Oa64UiobweA KtRg== X-Gm-Message-State: AOAM532t3gzpTtZ5j7Nisvz5KqrU+7Dlx2l1IlWYKUQvElZhBocMIeeu k66S1vO4ZzLAMFfq8scvLeTGaL+dnkt3Ffh1WgnSPjoc4zgZvudURj9oPWJl+lRZZCYOa41AoCJ Qs5MTorzt4htOmpLgq/KZ52fEGWLkAvKpkvv+vlY= X-Received: by 2002:a37:5ac3:: with SMTP id o186mr7007224qkb.272.1592646705789; Sat, 20 Jun 2020 02:51:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyxw2gdpUHiYd1xuaAPexkINxCzXpz7GO5BM8NPQaJBMLzb0YFTibshOiCn/B+FSjqkRcwJjg== X-Received: by 2002:a37:5ac3:: with SMTP id o186mr7007211qkb.272.1592646705450; Sat, 20 Jun 2020 02:51:45 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:c9e1::359]) by smtp.gmail.com with UTF8SMTPSA id f7sm8473472qkk.88.2020.06.20.02.51.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 20 Jun 2020 02:51:44 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev To: 孙世龙 sunshilong Subject: Re: Why does “page allocation failure” occur whereas there are still “58*4096kB (C)” could be used? In-Reply-To: References: <459330.1592542115@turing-police> <466244.1592550842@turing-police> Mime-Version: 1.0 Date: Sat, 20 Jun 2020 05:51:43 -0400 Message-ID: <547715.1592646703@turing-police> Cc: Kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5420418804944407111==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============5420418804944407111== Content-Type: multipart/signed; boundary="==_Exmh_1592646703_62491P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1592646703_62491P Content-Type: text/plain; charset=us-ascii > How can I know whether scatter/gather is available or not? > In another word, when it's available and when it's not? > I do not intend to ask the behavior of gadget driver. > I just wonder how I can confirm it in general. The following applies for device features in general, not just scatter/gather. Sometimes you get lucky, and the bus standard in use (PCI, USB, SPI/I2C, etc) mandates that the feature is supported in a standard way. So if you're writing a device driver for a specific card that uses a Wombat 9348j chipset, you'll probably need to get in touch with the company that makes the Wombat 9348j chipset and get the data sheet for it, and that will hopefully have the chipset programming details needed. If you're unlucky, the company won't give you the datasheet, or it won't contain the info, so you get to reverse engineer the chipset. One popular technique is to look at *other* chips in the Wombat 93 series, determine via some means whether those chipsets support scatter-gather, and how it's enabled. Then you put the same code in your driver, and see what happens. Possibility 1: Scatter-gather works just fine and the 16K I/O ends up in the 4 pages you allocated. Success! Possibility 2: It doesn't work,and the 16K of I/O hits your first 4K page, and the next 3 sequential pages even though they're something else, and your kernel crashes and burns because you just overlaid 12K worth of page tables or struct tasks or something important. Possibility 3: It doesn't work, but it takes you a while to find out because during your tests, the 4 pages happened to be allocated next to each other. It has happened that nobody notices until the driver is part of the mainline kernel, which is usually embarrassing... Possibility 4: It doesn't work, and the bit that says "use scatter/gather" in the IO command structure on the other chipsets actually enables the undocumented auto-defenestration capability of the chipset. This is usually worse than just embarrassing... --==_Exmh_1592646703_62491P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBXu3cLQdmEQWDXROgAQL/sxAAtn56G7mqxHFZOavvxuIo5SNYPRST7cmn 258vsotiplHvt0Hdp/t8LJwUuUuEz+AAkeLR9BORfNo0xz4Ez+dbWb/mGb/Rvj+a R0TWN7M199EqtS/9MWMRa1nagrZzf9R4bDT2wMlEpNmZpshHL3Cl66FGq1IVeue7 4+GYid821FxC+j8qUYSFNiHYqqvKpsx+pZnjKkndRKDXVq2FiNVUxZhhUG9cuQC8 YLXbkKtqg13xMQWi97pCq4BFq2HbCzDy6S8/EKyyMlR/FqdGR5JyBWP6p4EUFhYR jvAAStxwGkIerwrTsRs7goRdNwksTjoISPEDWOwW+KV9hxftCszltV/sziod33N7 QEES/VivlBmq/XsEu1J/p26hfPobzL2qhN8VNk37+nMBrnbaAhp2CoDJrC8+t7NO cHbpIjKvmJL5dK2TPkqmVIoInbrH2nRwVl5ff/f9oMl7uMBlRf5kJ6EPExlrq8Xa kyr/FlSdaV3J0qyGVwNG/qcvl7P58JQExKr2F6E7YcD5P+3jkS3htjjWUaqj7qD4 Wkdn0VATMz5sdaqSf/xpeTWu3E6SWMYpdtnd2zsME/VALTEqvI9vYHHN0o5pA68a KtogitI4ys6WPAOEpXakAeOEJPF4rxgLhjR0GC1tlIFnB37zq+53rNUKLQK43stc V0d7cIkKvyI= =218+ -----END PGP SIGNATURE----- --==_Exmh_1592646703_62491P-- --===============5420418804944407111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============5420418804944407111==--