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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 77EFDC433E0 for ; Fri, 26 Jun 2020 17:23:16 +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 336A42065F for ; Fri, 26 Jun 2020 17:23:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 336A42065F 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 1jos3i-0000GP-QE; Fri, 26 Jun 2020 13:22:38 -0400 Received: from omr2.cc.ipv6.vt.edu ([2607:b400:92:8400:0:33:fb76:806e] helo=omr2.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 1jos3g-0000GI-Kq for Kernelnewbies@kernelnewbies.org; Fri, 26 Jun 2020 13:22:36 -0400 Received: from mr3.cc.vt.edu (mr3.cc.ipv6.vt.edu [IPv6:2607:b400:92:8500:0:7f:b804:6b0a]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id 05QHMWcJ003762 for ; Fri, 26 Jun 2020 13:22:35 -0400 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by mr3.cc.vt.edu (8.14.7/8.14.7) with ESMTP id 05QHMRcN022360 for ; Fri, 26 Jun 2020 13:22:32 -0400 Received: by mail-qt1-f198.google.com with SMTP id u48so6944773qth.17 for ; Fri, 26 Jun 2020 10:22:32 -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=Z1uLj1Gf++2uI7yMIsoMAubzh7EPoa4w7JJaDJ0ZFHo=; b=F8Xces64wU8G1opleNdZ5QBiqpK7MVVyfHa7NDsiif2yfqAOoFrrs05+FSYdWxC/Pr xwg/ck44HHW3rNGQEYuMvOI0eyZvgo0WqI7ccdrt0/sz1gEqdaY/oKr3D3/hzdTFep4v i8mJrSIJNxS3uInAoErGvbzp0sOlr0buIkh2QQvQAsctQEHNJj2UJ3mrpY8FHZupSUUA 0felVGi9WDar09xB/arDmoS3rY9yiM9OMkJ1w6wJzG9BNdx7OaIZXXOcsatC4YSpWctE xRPKgtKC++KynvmIJmdbx96NIJF0rpvf03nv5e5Fyvp3LT/izO+MKoyzlxhqpJhaR2bl rm+Q== X-Gm-Message-State: AOAM531EgCEEAWtZ+FE7PcgTR3OXxwM28BNczT07P5u8gkfDddu0bKiS d0NzIpgQzTG8p/OwsubhUYVfPnJx/g+/RbxWPoVCuhNLN4oV0Wg/CHuFZfDy1bXhmUSopoOI2Dz Asp7n/nrpGaEH5A3KeLcZf39nqLuUZhX6X6kdH8E= X-Received: by 2002:ac8:3893:: with SMTP id f19mr4007672qtc.184.1593192146853; Fri, 26 Jun 2020 10:22:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwUsATVVW8gGen3+b4BQYPUn/CQjdbfrq/oq6WCfTbCBb1yb+Ck6BuPbrBAwzVMuapFAr5vMQ== X-Received: by 2002:ac8:3893:: with SMTP id f19mr4007644qtc.184.1593192146523; Fri, 26 Jun 2020 10:22:26 -0700 (PDT) Received: from turing-police ([2601:5c0:c001:c9e1::359]) by smtp.gmail.com with UTF8SMTPSA id r5sm10158092qtc.20.2020.06.26.10.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jun 2020 10:22:24 -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: Are there some potential problems that I should be aware of if I allocate the memory which doesn't have any relation to peripheral hardwares(i.e. DMA, PCI, serial port and etc) by vmalloc() instead of kmalloc()? In-Reply-To: References: <20200626141319.GC4140284@kroah.com> Mime-Version: 1.0 Date: Fri, 26 Jun 2020 13:22:23 -0400 Message-ID: <67284.1593192143@turing-police> Cc: Greg KH , 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="===============5058849328804734331==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============5058849328804734331== Content-Type: multipart/signed; boundary="==_Exmh_1593192143_9189P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1593192143_9189P Content-Type: text/plain; charset=us-ascii On Fri, 26 Jun 2020 23:36:05 +0800, 孙世龙 sunshilong said: > Thank you for your attention to this matter. > > >Why are you having so many issues in allocating memory? > I often saw the page allocation failure recently. I must resolve this problem. As I mentioned a few days ago, the fact that a high-order allocation failed does not necessarily mean a total failure, as often the driver can instead allocate several smaller areas. > I have no choice other than disabling these options > (i.e. CONFIG-MIGRATION and CONFIG-COMPACTION) > since I am using a real-time OS. First, Linux is not a real-time OS. Second, "real time" doesn't automatically imply those two options have to be disabled. It's trickier to do it when you have hard real-time limits, but it's not impossible. > The current code snippet is using kmalloc() and often encounter the > aforementioned problem. Having said that about migration and compaction, anybody sane who's writing for an actual real-time system already knows *exactly* how much memory the system will use, and the critical allocations are done at system startup to guarantee that (a) the allocations succeed and (b) most of the memory is pre-allocated with little chance of causing fragmentation. > So I want to use vmalloc() instead of kmalloc(). What do you think about it? > The memory to be allocated doesn't have any relation to any peripheral > hardware (i.e. DMA, PCI, serial port, etc) indeed. It's just used to > store a struct > array which indicates the usage of other resources. So as per the above - you allocate one struct array at driver load time for this stuff. You already know how big the structure/array has to be based on the maximum number of devices or whatever you're trying to track. And if you don't know the maximum, you're not doing real time programming. Or at least not correctly. --==_Exmh_1593192143_9189P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQIVAwUBXvYuzwdmEQWDXROgAQKhgg/+Pdiaxymrq80gsBfXa1C9BumnNf/2ECHg SloO4MVnovoVsIBHYrUzv8rv+jjbF+J91JY0izTvAXc2Uf/VX6aKYgGkzCfIZcGZ J2njtyRzZ+EFcDphnT+ZPD6ITwa/qYt4a7pDPfXdDyuGaOC76YaN+hb40joam/DQ Mq3JkpSdzWbiu7qbrutx1f2PjoJvw3ciz82n828E5dNIYgDj09cpMQVrewhPQVOH qRaseYHbcfvx62KQGWYeEoggknHXKtsGmBqVdqOiRNmz6CMwLqxkwA6N6/Cp0eOM d4/NCE7cc2PnivZF4K4EUPyCbKzXCKGmUklcGSnKd+32yo7hg2flclE2l3i3byCI wyelitqoM8XMnvtc2jlXXX4P41RKa72GN0RrCyrDzLbEXUCe6dUSbouy+mJ2wZ8h J0boqbKwQbhzQxnWu9dikRK+03T6Tc/54WQQr8EFEuKu+Md3Pplq+eAAGUrVEGHy tLZ153ERwaWM5/Psz+CwEU2y/ZoYdj3DioPTi4hybFrpHe7qwRYS6kznHN27safW 2/vf32DJfj3VSZOH2sGta1pE0nwKpQv/TmQM6z0nHC/E6O1yihRLX1fbg2shyGeM oXwffOpe4+ZyKGKx+W7is9OM/nsAJ2GJiFIDwZqfSH7mgeta8M22mk7KyhOJ//wF cVzIiAOQV1U= =P1oQ -----END PGP SIGNATURE----- --==_Exmh_1593192143_9189P-- --===============5058849328804734331== 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 --===============5058849328804734331==--