CINXE.COM

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>LKML: Mark Rustad: Re: [PATCH 2.6.15-rc5] hugetlb: make make_huge_pte global and fix coding style</title><link href="/css/message.css" rel="stylesheet" type="text/css" /><link href="/css/wrap.css" rel="alternate stylesheet" type="text/css" title="wrap" /><link href="/css/nowrap.css" rel="stylesheet" type="text/css" title="nowrap" /><link href="/favicon.ico" rel="shortcut icon" /><script src="/js/simple-calendar.js" type="text/javascript"></script><script src="/js/styleswitcher.js" type="text/javascript"></script><link rel="alternate" type="application/rss+xml" title="lkml.org : last 100 messages" href="/rss.php" /><link rel="alternate" type="application/rss+xml" title="lkml.org : last messages by Mark Rustad" href="/groupie.php?aid=24984" /><script> var _paq = window._paq = window._paq || []; /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ _paq.push(["setDoNotTrack", true]); _paq.push(["disableCookies"]); _paq.push(['trackPageView']); _paq.push(['enableLinkTracking']); (function() { var u="//m.lkml.org/"; _paq.push(['setTrackerUrl', u+'matomo.php']); _paq.push(['setSiteId', '1']); var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; g.async=true; g.src=u+'matomo.js'; s.parentNode.insertBefore(g,s); })(); </script></head><body onload="es.jasper.simpleCalendar.init();" itemscope="itemscope" itemtype="http://schema.org/BlogPosting"><table border="0" cellpadding="0" cellspacing="0"><tr><td width="180" align="center"><a href="/"><img style="border:0;width:135px;height:32px" src="/images/toprowlk.gif" alt="lkml.org" /></a></td><td width="32">聽</td><td class="nb"><div><a class="nb" href="/lkml"> [lkml]</a> 聽 <a class="nb" href="/lkml/2005"> [2005]</a> 聽 <a class="nb" href="/lkml/2005/12"> [Dec]</a> 聽 <a class="nb" href="/lkml/2005/12/10"> [10]</a> 聽 <a class="nb" href="/lkml/last100"> [last100]</a> 聽 <a href="/rss.php"><img src="/images/rss-or.gif" border="0" alt="RSS Feed" /></a></div><div>Views: <a href="#" class="nowrap" onclick="setActiveStyleSheet('wrap');return false;">[wrap]</a><a href="#" class="wrap" onclick="setActiveStyleSheet('nowrap');return false;">[no wrap]</a> 聽 <a class="nb" href="/lkml/mheaders/2005/12/10/7" onclick="this.href='/lkml/headers'+'/2005/12/10/7';">[headers]</a>聽 <a href="/lkml/bounce/2005/12/10/7">[forward]</a>聽 </div></td><td width="32">聽</td></tr><tr><td valign="top"><div class="es-jasper-simpleCalendar" baseurl="/lkml/"></div><div class="threadlist">Messages in this thread</div><ul class="threadlist"><li class="root"><a href="/lkml/2005/12/9/130">First message in thread</a></li><li><a href="/lkml/2005/12/9/210">Mark Rustad</a><ul><li><a href="/lkml/2005/12/9/228">Hugh Dickins</a><ul><li class="origin"><a href="">Mark Rustad</a></li></ul></li></ul></li></ul></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerl.gif" width="32" height="32" alt="/" /></td><td class="c" rowspan="2" valign="top" style="padding-top: 1em"><table><tr><td><table><tr><td class="lp">From</td><td class="rp" itemprop="author">Mark Rustad <></td></tr><tr><td class="lp">Subject</td><td class="rp" itemprop="name">Re: [PATCH 2.6.15-rc5] hugetlb: make make_huge_pte global and fix coding style</td></tr><tr><td class="lp">Date</td><td class="rp" itemprop="datePublished">Sat, 10 Dec 2005 00:01:28 -0600</td></tr></table></td><td></td></tr></table><pre itemprop="articleBody">On Dec 9, 2005, at 4:12 PM, Hugh Dickins wrote: > On Fri, 9 Dec 2005, Mark Rustad wrote: >> On Dec 9, 2005, at 2:37 PM, Hugh Dickins wrote: >>> >>> You're not the only one to have trouble with recent remap_pfn_range >>> changes. >>> Would you let us know what you were doing, that you can no longer >>> do? >>> Some of the change may need to be reverted. >> >> Well, our driver had been allocating two 320MB and one 128MB range >> of memory, >> each of the three being contiguous. These were allocated by >> allocating lots of >> 1MB groups of pages until we got a contiguous range, then the >> unneeded pages >> were freed. > > I can understand that you might be dissatisfied with that. Not dissatisfied really. It worked fine, not optimal of course, but it worked. Since change was forced by kernel changes, it made sense to try to do better while making it work again. >> These areas were then mapped into the application with >> remap_pfn_range. We >> have been running on a SuSE kernel derived from 2.6.5 for a long >> time where >> this worked fine, even for gdb to access during debugging. Now >> that we are >> moving to a more current kernel, changes were needed mainly to >> allow gdb to >> access these shared memory areas. > > Okay, I think I get the picture. 2.6.15-rc5 would work if you used > three adjacent mmaps, but that would involve changes to your driver > and > to your userspace, so you thought better to do it another way anyway. We had to change the remap_pfn_range though, because that was no longer usable if one wanted to be able to access the memory from gdb, which is a requirement for debugging. Also, all of our shared memory had been coming out of low memory - the change to hugepages now has lifted that restriction, which is also a much better place to be. >> I had messed with simply taking the large memory by restricting >> the kernel's >> memory range with mem=, but gdb still can't get to the pages >> because it >> believes that they are for I/O (there would be no struct page in >> that case). >> >> Given the situation, using hugepages seemed more attractive >> anyway, so I just >> decided to go that way and specify hugepages=192 on the kernel >> command line. >> >> We also have a single page shared between our processes and the >> driver, but we >> now use the new insert_single_page call for that, which works >> nicely. It >> seemed to me that calling that for the each of the single pages in >> our 768M of >> shared memory was silly, so I went the hugepage route, and that >> proved to be >> less trouble than I had expected. I feel like things now are >> really where they >> should have been all along. > > Hmm. Well, I share the doubts Dave and Adam have expressed. Out- > of-tree > drivers making up their own page tables are likely to break and be > broken, > and the more so once you get into hugepages. You'll be much more > portable > from release to release if you stick with lots of vm_insert_pages, > silly > as all that does seem, yes. Sorry, I don't have a better answer to > hand. Well, portability is less important than maintainability. I think being able to call make_huge_pte likely makes what I'm doing somewhat more maintainable than duplicating the code locally. I would prefer an explicit call to do the mapping, but I don't really expect that there are very many things doing memory mapping on this scale, so I have not submitted a patch to implement that. I am also not very confident in my understanding of this area of the kernel to think that I could provide an adequate patch, even though the code that I have is working for our application. Do you foresee problems in using the make_huge_pte function? I am also calling alloc_huge_page, free_huge_page, huge_pte_alloc, set_huge_pte_at and pte_none in my code. I only had to change make_huge_pte in order to be able to call it - the other functions were already callable. Note that in my case, the driver is built into the kernel - it is not a module. My patch for changing make_huge_pte does not export that symbol from the kernel for use by modules. -- Mark Rustad, MRustad@mac.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html">http://vger.kernel.org/majordomo-info.html</a> Please read the FAQ at <a href="http://www.tux.org/lkml/">http://www.tux.org/lkml/</a> </pre></td><td width="32" rowspan="2" class="c" valign="top"><img src="/images/icornerr.gif" width="32" height="32" alt="\" /></td></tr><tr><td align="right" valign="bottom"> 聽 </td></tr><tr><td align="right" valign="bottom">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerl.gif" width="32" height="32" alt="\" /></td><td class="c">聽</td><td class="c" valign="bottom" style="padding-bottom: 0px"><img src="/images/bcornerr.gif" width="32" height="32" alt="/" /></td></tr><tr><td align="right" valign="top" colspan="2"> 聽 </td><td class="lm">Last update: 2005-12-10 07:05 聽聽 [from the cache] 漏2003-2020 <a href="http://blog.jasper.es/">Jasper Spaans</a>|hosted at <a href="https://www.digitalocean.com/?refcode=9a8e99d24cf9">Digital Ocean</a> and my Meterkast|<a href="http://blog.jasper.es/categories.html#lkml-ref">Read the blog</a></td><td>聽</td></tr></table><script language="javascript" src="/js/styleswitcher.js" type="text/javascript"></script></body></html>