page table fault, which should map kernel virtual address space
Hallo,
this is about 'NKPT' definition, 'kernel_map' submaps,
and 'vm_map_findspace' function.
Variable 'kernel_map' is used to manage kernel virtual address
space. When 'vm_map_findspace' function deals with 'kernel_map'
then 'pmap_growkernel' function is called.
At least in 'i386' architecture, pmap implementation uses
'pmap_growkernel' function to allocate missing page tables.
Missing page tables are problem, because no one checks
'pte' pointer for validity after use of 'vtopte' macro.
'NKPT' definition defines a number of preallocated
page tables during system boot.
Beyond 'kernel_map', some submaps of 'kernel_map' (buffer_map,
pager_map,...) exist as result of 'kmem_suballoc' function call.
When this submaps are used (for example 'kmem_alloc_nofault'
function) and its virtual address subspace is at the end of
used kernel virtual address space at the moment (and above 'NKPT'
preallocation), then missing page tables are not allocated
and double fault can happen.
I have met this scenario and solved it by increasing
page tables preallocation count ('NKPT' definition).
It's temporary solution which works for the present.
Can someone more advanced and sacred in virtual memory module
solve it (in 'vm_map_findspace' function for example)? Or tell
me that the problem is elsewhere...
Thanks, Svata
--
View this message in context:
http://old.nabble.com/page-table-fault%2C-which-should-map-kernel-virtual-address-space-tp29760054p29760054.html
Sent from the freebsd-hackers mailing list archive at Nabble.com.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally
Kostik,
On Sun, Sep 19, 2010 at 09:41:46PM +0300, Kostik Belousov wrote:
> On Sun, Sep 19, 2010 at 10:14:06AM +0200, Jeremie Le Hen wrote:
> > Hi Alexander,
> >
> > On Thu, Aug 05, 2010 at 09:14:46PM +0200, Jeremie Le Hen wrote:
> > > On Tue, Aug 03, 2010 at 11:46:51AM -0400, Alexander Kabaev wrote:
> > > >
> > > > I have no objection, but think we should cave in and investigate the
> > > > possibility of using linker script wrapping libc.so in FreeBSD-9.0:
> > > >
> > > > Below is Linux' counterpart:
> > > >
> > > > /* GNU ld script
> > > >Use the shared library, but some functions are only in
> > > >the static library, so try that secondarily. */
> > > > OUTPUT_FORMAT(elf32-i386)
> > > > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED
> > > > ( /lib/ld-linux.so.2 ) )
> > >
> > > Ok. For now can you commit the proposed modification. I'll try to make
> > > a patch with your proposal.
> >
> > The attached patch does two things: It modifies bsd.lib.mk to support ld
> > scripts for shared libraries and adds such a script to replace the
> > /usr/lib/libc.so symlink to /lib/libc.so.X.
> >
> > Basically, SHLIB_LDSCRIPT is defined in lib/libc/Makefile and points to
> > the file containing the script itself:
> > GROUP ( @@SHLIB@@ /usr/lib/libssp_nonshared.a )
> >
> > During make install, @@SHLIB@@ will be replaced by the real path of the
> > shared library.
>
> You did not included $FreeBSD$ tag into libc.so script. I think it would be
> useful to have.
Sure. I will send an updated patch a little later.
> Could you, please, comment why the script is not installed during the
> world build stage ? My question is, would the buildworld use the script
> for linkage ?
libc.ld, the generated ldscript in ${.OBJDIR}, is built along with
libc.so.7 which is built only once (stage 4.2 of buildworld).
In order to get buildworld use the ld script, it would require to
generate it twice: once during stage 4.2 using
/usr/obj/usr/src/tmp/lib/libc.so.7 and another one afterward using
/lib/libc.so.7.
Besides I didn't see an advantage to do this because when compiling the
base system, CFLAGS and LDFLAGS are well controlled so -fstack-protector
will be provided when linking the program. On the other hand, the patch
I propose is required for the numerous ports for which we do not control
linking flags; lang/perl comes into my mind. If you want to compile it
with SSP, you have to patch its build infrastructure (see ports/138228).
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: zfs + uma
on 19/09/2010 11:27 Jeff Roberson said the following: > On Sun, 19 Sep 2010, Andriy Gapon wrote: > >> on 19/09/2010 01:16 Jeff Roberson said the following: >>> Additionally we could make a last ditch flush mechanism that runs on each >>> cpu in >>> turn and flushes some or all of the buckets in per-cpu caches. Presently >>> that is >>> not done due to synchronization issues. It can't be done from a central >>> place. >>> It could be done with a callout mechanism or a for loop that binds to each >>> core >>> in succession. >> >> I like all of the tree above approaches. >> The last one is a bit hard to implement, the first two seem easier. > > All the last one requires is a loop calling sched_bind() on each available > cpu. Something like cache_drain() but with sched_bind() in the loop? critical_enter() would be probably also needed to avoid preemption and conflict while acting on cache buckets? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally
On Mon, Sep 20, 2010 at 06:29:25PM +0200, Jeremie Le Hen wrote:
> Kostik,
>
> On Sun, Sep 19, 2010 at 09:41:46PM +0300, Kostik Belousov wrote:
> > On Sun, Sep 19, 2010 at 10:14:06AM +0200, Jeremie Le Hen wrote:
> > > Hi Alexander,
> > >
> > > On Thu, Aug 05, 2010 at 09:14:46PM +0200, Jeremie Le Hen wrote:
> > > > On Tue, Aug 03, 2010 at 11:46:51AM -0400, Alexander Kabaev wrote:
> > > > >
> > > > > I have no objection, but think we should cave in and investigate the
> > > > > possibility of using linker script wrapping libc.so in FreeBSD-9.0:
> > > > >
> > > > > Below is Linux' counterpart:
> > > > >
> > > > > /* GNU ld script
> > > > >Use the shared library, but some functions are only in
> > > > >the static library, so try that secondarily. */
> > > > > OUTPUT_FORMAT(elf32-i386)
> > > > > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED
> > > > > ( /lib/ld-linux.so.2 ) )
> > > >
> > > > Ok. For now can you commit the proposed modification. I'll try to make
> > > > a patch with your proposal.
> > >
> > > The attached patch does two things: It modifies bsd.lib.mk to support ld
> > > scripts for shared libraries and adds such a script to replace the
> > > /usr/lib/libc.so symlink to /lib/libc.so.X.
> > >
> > > Basically, SHLIB_LDSCRIPT is defined in lib/libc/Makefile and points to
> > > the file containing the script itself:
> > > GROUP ( @@SHLIB@@ /usr/lib/libssp_nonshared.a )
> > >
> > > During make install, @@SHLIB@@ will be replaced by the real path of the
> > > shared library.
> >
> > You did not included $FreeBSD$ tag into libc.so script. I think it would be
> > useful to have.
>
> Sure. I will send an updated patch a little later.
>
> > Could you, please, comment why the script is not installed during the
> > world build stage ? My question is, would the buildworld use the script
> > for linkage ?
>
> libc.ld, the generated ldscript in ${.OBJDIR}, is built along with
> libc.so.7 which is built only once (stage 4.2 of buildworld).
>
> In order to get buildworld use the ld script, it would require to
> generate it twice: once during stage 4.2 using
> /usr/obj/usr/src/tmp/lib/libc.so.7 and another one afterward using
> /lib/libc.so.7.
>
> Besides I didn't see an advantage to do this because when compiling the
> base system, CFLAGS and LDFLAGS are well controlled so -fstack-protector
> will be provided when linking the program. On the other hand, the patch
> I propose is required for the numerous ports for which we do not control
> linking flags; lang/perl comes into my mind. If you want to compile it
> with SSP, you have to patch its build infrastructure (see ports/138228).
You make the script only useful for the stack protection. If build process
does not use libc.so script, but installed system does, you
- require to maintain two places where (not much) hypothetical libc
changes should go;
- make it very puzzling to debug the issues with the build of the usermode.
Please, do this in the consistent manner, so that the script can be adopted
for other uses.
pgpmIqRGfOcIA.pgp
Description: PGP signature
Re: zfs + uma
on 19/09/2010 11:42 Andriy Gapon said the following: > on 19/09/2010 11:27 Jeff Roberson said the following: >> I don't like this because even with very large buffers you can still have >> high >> enough turnover to require per-cpu caching. Kip specifically added UMA >> support >> to address this issue in zfs. If you have allocations which don't require >> per-cpu caching and are very large why even use UMA? > > Good point. > Right now I am running with 4 items/bucket limit for items larger than 32KB. But I also have two counter-points actually :) 1. Uniformity. E.g. you can handle all ZFS I/O buffers via the same mechanism regardless of buffer size. 2. (Open)Solaris does that for a while and it seems to suit them well. Not saying that they are perfect, or the best, or an example to follow, but still that means quite a bit (for me). -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: zfs + uma
on 19/09/2010 01:16 Jeff Roberson said the following: > Additionally we could make a last ditch flush mechanism that runs on each cpu > in How would you qualify a "last ditch" trigger? Would this be called from "standard" vm_lowmem look or would there be some extra check for even more severe memory condition? > turn and flushes some or all of the buckets in per-cpu caches. Presently that > is > not done due to synchronization issues. It can't be done from a central > place. > It could be done with a callout mechanism or a for loop that binds to each > core > in succession. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
