Date: Sun, 13 Jul 2003 22:16:12 -0700 From: David Schultz <das@FreeBSD.org> To: Bosko Milekic <bmilekic@technokratis.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern subr_param.c sys_pipe.c src/sys/sys pipe.h Message-ID: <20030714051612.GA27609@HAL9000.homeunix.com> In-Reply-To: <20030710153734.GA1101@technokratis.com> References: <200307080457.h684vRM7009343@gw.catspoiler.org> <20030708000257.D6158@odysseus.silby.com> <20030708004340.T6733@odysseus.silby.com> <3F0B199E.A3C980D2@imimic.com> <20030710182436.GA6484@HAL9000.homeunix.com> <3F0DBC39.891A91A@imimic.com> <20030710153734.GA1101@technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 10, 2003, Bosko Milekic wrote: > > On Thu, Jul 10, 2003 at 02:19:21PM -0500, Alan L. Cox wrote: > [...] > > > That would alleviate the KVA pressure, since the mapping would be > > > very temporary and you could even get away with just a single > > > page. However, it would still tie up the associated physical > > > memory until the pipe is read, which may not be soon at all. Is > > > there a reason for the memory to be wired, other than that the > > > data is easier to track down while the sending process' PTEs are > > > still there? I would expect that you could instead just look up > > > the appropriate vm_object and lazily fault in the appropriate pages > > > on the receiver's side, modulo a few details such as segfault handling. > > > But perhaps I'm missing something... > > > > It's a matter of priorities. With the growth trend in physical memory > > sizes (and PAE), I see more problems due to KVA pressure than > > unnecessarily wired memory. A recent, and fairly visible example, was > > the vnode autosizing problems that had to be fixed prior to 5.1-RELEASE. > > With the recent bug reporting regarding kmem_map being too small > coming in, I'd have to say that I agree with that assertion. Address > space has become more expensive than memory, at least on ia32, and > it's gotten to the point where we need to re-evaluate some of our > autosizing and max size constants (for example, see VM_KMEM_SIZE_MAX). /me returns from vaction to a flood of email. phk's proposal to decouple the buffer cache from the kernel address space will probably be a great help here, but you're right that VM_KMEM_SIZE_MAX should be reevaluated. It doesn't make sense to have kmem_map and mb_map capped in the 200MB range when you've configured 2 GB of KVA and have 4 GB of physical memory. Do you think a default max of half of KVA would make sense? As for priorities, it's true that more people are hitting KVA limits, not physical memory limits. On the other hand, I tend to view the KVA limitation as a temporary problem (at least in the mainstream PC and server markets) and physical memory limitations as a permanent problem. I expect most of the people who are hitting those limits today will be using 64-bit architectures within the next 4 years, and that's before FreeBSD 6.0 will be ready. So yes, some work on KVA issues is needed right now, but we don't need an industrial-strength solution that involves rewriting FreeBSD as a microkernel. ;-) On the other hand, physical memory is cheap enough that it may not be worth bothering over a few wired pages. Alan is probably right; the wired memory for large pipe writes may amount to very little. It's certainly true that it no longer makes sense to be stingy about memory, and yet sloppiness doesn't fly either. The reason for having pageable memory in the first place is that people will always want to solve problems that are larger than the amount of memory they have. But as I've admitted, large pipes---even if they aren't consumed immediately---probably don't amount to much wired memory. Actually, pipes could be the least of our worries in terms of both KVA and wired memory. >>> Start reading here <<< So philosophizing aside, pushing the pmap_qenter() into the receiver sounds like a deceptively simple and perfectly reasonable optimization.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030714051612.GA27609>