headers
Terry Lambert | 1 Feb 2003 01:47
Picon

Re: PAE (was Re: bus_dmamem_alloc_size())

Peter Wemm wrote:
> Gary Thorpe wrote:
> > Would this be part of a unified buffer-cache scheme though? If I have
> > been following correctly, this memory cannot be directly mapped into
> > processes address space (i.e. a process in one "segment" cannot access
> > directly memory in another "segment"), so how would it be useful as a
> > cache? Wouldn't this need lots of data copying as in bounce buffers?
> 
> It the nasty PSE36 hack that cant be used for this.  PAE works fine as
> cache since it is all available to all processes.

What Peter said: the thing you don't get is the ability to have more
than 4G of KVA + UVA space, unless you split the VM and buffer cache.

Also what Peter said about the performance penalty that comes from
PAE, and what I said about the reliability penalty from #ifdef'ing
and seperately maintaining the code side-by-side.

-- Terry

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 0 comments |
headers
phk | 4 Feb 2003 12:29
Picon
Favicon
Gravatar

length of device names.


There are some irritating implications of making device names truly
variable size, and I am not yet comfortable making the semantic
changes it causes, people calle makedev() and make_dev() from the
damnest places.

In fact, I am not even convinced doing the work would have a positive
payoff in the end compared to sticking with KISS and just taking
the memory hit for a longer default buffer.

I decided to increase the limit to 63 characters for now, and revisit
the issue if this limit ever becomes a problem.  I personally expect
and hope that any device name approaching than 63 characters would
hit against other (esthetical) boundaries first.

We currently allocate 50 dev_t's at compile time (to be able to
make it until malloc(9) works) and the rest with malloc(9).  The
current size of a dev_t is 140 bytes + space for the name, so in
theory we can allow for 116 bytes long names at a net cost of only
50 times the increase since malloc(9) already allocates us 256 bytes
buckets, so the net cost of this change was 2400 bytes.

Summary: I'm shelving the unlimited name length for now, hoping that
63 or subsequently 116 will be enough to cater for our needs.

Poul-Henning

In message <200302041107.h14B7ST1060100 <at> repoman.freebsd.org>, Poul-Henning Kamp
 writes:
>phk         2003/02/04 03:07:28 PST
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mikhail Teterin | 4 Feb 2003 16:46

dlclose() vs. atexit()

	[Moved to -arch]

On Tuesday 04 February 2003 03:26 am, Alfred Perlstein wrote:
= * Wes Peters <wes <at> softweyr.com> [030203 23:41] wrote:
= > On Mon, 2003-02-03 at 18:58, Mikhail Teterin wrote:
= > > There remains an unresolved issue with mplayer on FreeBSD -- some
= > > of the libraries it dlopens and dlcloses are calling atexit() in
= > > between with their own functions.
= > > 
= > > This causes SEGFAULTs in exit(), which tries to call those
= > > functions. The application catches the signals and would not quit
= > > until SIGKILL-ed.
= > > 
= > > This does not affect Linux, where, reportedly, calls to atexit()
= > > are treated differently if made from dlopened code. I'm not sure
= > > how best to fix this (Call _exit()? Remove signal handlers before
= > > exit()?), but something needs to be done...

= > I think ideally we'd want dlclose to be able to deinstall any
= > atexit handlers that were installed by library functions. The
= > most straight- forward path to this I can see is an atexit-remove
= > call that can be passed a start and end address and will remove
= > any function references found between the two. dlclose could call
= > this function with the start and end addresses of the library text
= > segment to remove any exit handlers in the library code space.

= > I can probably take a look at this later in the week if this seems
= > like a reasonable approach.

= Please see if you can emulate the glibc behaviour just to ease
(Continue reading)

Permalink | Reply | 6 comments |
headers
Chip Norkus | 4 Feb 2003 17:25

Re: dlclose() vs. atexit()

On Tue Feb 04, 2003; 10:46AM -0500 Mikhail Teterin propagated the following:

[snip]
> 
> Yet another plan would be to have the atexit() call simply increase the
> ref-count of the library a handler is from, so it will not actually be
> unloaded by dlclose(). But that will be yet another implementation...
> 

I'm not sure this would be a good idea.  I have a program which
uses dynamic libraries to introduce code, and which can unload or
reload them at any time and keep on running.  I am especially worried
about the reload case, because what often happens is that an old
version of the .so is unloaded (dlclosed) and then a new version
is loaded (dlopened).  If the old version stays around, I'm afraid
there would be some symbol collision.  Correct me if I'm wrong,
though.

I think the Solaris approach you mentioned above is by far the best
and most correct sounding approach.

> 	-mi
> 

-wd
--

-- 
chip norkus; unix geek and programmer;          wd <at> arpa.com
"question = (to) ? be : !be;" --Shakespeare     http://telekinesis.org/

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Grant | 4 Feb 2003 17:42
Picon
Picon
Favicon

Re: dlclose() vs. atexit()

On Tue, 4 Feb 2003, Chip Norkus wrote:

> On Tue Feb 04, 2003; 10:46AM -0500 Mikhail Teterin propagated the following:
>
> [snip]
> >
> > Yet another plan would be to have the atexit() call simply increase the
> > ref-count of the library a handler is from, so it will not actually be
> > unloaded by dlclose(). But that will be yet another implementation...
> >
>
> I'm not sure this would be a good idea.  I have a program which
> uses dynamic libraries to introduce code, and which can unload or
> reload them at any time and keep on running.  I am especially worried
> about the reload case, because what often happens is that an old
> version of the .so is unloaded (dlclosed) and then a new version
> is loaded (dlopened).  If the old version stays around, I'm afraid
> there would be some symbol collision.  Correct me if I'm wrong,
> though.
>
> I think the Solaris approach you mentioned above is by far the best
> and most correct sounding approach.

I agree; I've done similar work with dlopened libraries which were
"updated" over time, dynamically.

The atexit() / dlclose() behaviour seems robust and "does the right
thing". If you want more complex behaviour (eg, persisting library state
while you update a dynamic library) then you have to roll your own.
That's not a big deal.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Terry Lambert | 4 Feb 2003 20:12
Picon

Re: dlclose() vs. atexit()

Mikhail Teterin wrote:
> Last time I brought this up, it was not clear, what The Right Thing to
> do is. Are these details mandatated by some standard out there, or is
> everyone on their own, and we should, indeed, do what Linux does, to not
> increase the enthropy?
> 
> Should, for example, exit handlers, which will still be valid after the
> dlclose() still be called at dlclose() or at the actual exit()? How
> about atexit() calls made between dlopen() and dlclose(), and not by the
> library but by the application, or by another library? Have each library
> get its own list of exit-handlers?
> 
> Or should it still be a global list, but examined by both dlclose()
> and exit() -- if an item on the list is about to become invalid after
> dlclose() (how can we know, BTW?), have dlclose() call it -- otherwise,
> leave it alone?

FWIW, the way Windows handles this is to have various entry point
to manage this:

	ProcessAttach		Called after a process attaches to
				a shared object
	ProcessDetach		Called before a process detaches a
				shared object
	ThreadAttach		Called after a thread attaches to
				a shared object
	ThreadDetach		Called before a thread detaches a
				shared object

The key here is that all processes have at least one thread.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Max Khon | 4 Feb 2003 20:42
Picon

Re: dlclose() vs. atexit()

hi, there!

> Yet another plan would be to have the atexit() call simply increase the
> ref-count of the library a handler is from, so it will not actually be
> unloaded by dlclose(). But that will be yet another implementation...

this will break applications which want to reload some
of the dlopen'ed modules

/fjoe

To Unsubscribe: send mail to majordomo <at> FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Permalink | Reply | 2 comments |
headers
Mikhail Teterin | 4 Feb 2003 21:05

Re: dlclose() vs. atexit()

On Tuesday 04 February 2003 02:42 pm, Max Khon wrote:
= hi, there!
= 
= > Yet another plan would be to have the atexit() call simply increase the
= > ref-count of the library a handler is from, so it will not actually be
= > unloaded by dlclose(). But that will be yet another implementation...
= 
= this will break applications which want to reload some
= of the dlopen'ed modules

I guess, I'm especially slow today. How will it break them? That is
what Solaris appears to be doing, BTW -- calling the exit-handler at
dlclose(), but leaving the library in memory:

	SunOS [...] 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R
	Loading the libraries
	./l0.so loaded as ff3a1458
	./l1.so loaded as ff3a17b8
	Library 0 calling atexit(ff260380)
	Library 1 calling atexit(ff350380)
	Unloading the libraries
	Exit handler ff350380 of library 0 is invoked
	ff3a1458 unloaded
	Exit handler ff260380 of library 1 is invoked
	ff3a17b8 unloaded
	Libraries unloaded. Returning

See, the exit handler for library 1 is called and does not crash, even
though it is defined in the already dlclosed library 0...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Max Khon | 4 Feb 2003 21:44
Picon

Re: dlclose() vs. atexit()

hi, there!

On Tue, Feb 04, 2003 at 03:05:53PM -0500, Mikhail Teterin wrote:

> = > Yet another plan would be to have the atexit() call simply increase the
> = > ref-count of the library a handler is from, so it will not actually be
> = > unloaded by dlclose(). But that will be yet another implementation...
> = 
> = this will break applications which want to reload some
> = of the dlopen'ed modules
> 
> I guess, I'm especially slow today. How will it break them? That is
> what Solaris appears to be doing, BTW -- calling the exit-handler at
> dlclose(), but leaving the library in memory:
> 
> 	SunOS [...] 5.8 Generic_108528-13 sun4u sparc SUNW,Sun-Fire-280R
> 	Loading the libraries
> 	./l0.so loaded as ff3a1458
> 	./l1.so loaded as ff3a17b8
> 	Library 0 calling atexit(ff260380)
> 	Library 1 calling atexit(ff350380)
> 	Unloading the libraries
> 	Exit handler ff350380 of library 0 is invoked
> 	ff3a1458 unloaded
> 	Exit handler ff260380 of library 1 is invoked
> 	ff3a17b8 unloaded
> 	Libraries unloaded. Returning
> 
> See, the exit handler for library 1 is called and does not crash, even
> though it is defined in the already dlclosed library 0...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Watson | 4 Feb 2003 23:52
Picon
Favicon

Re: length of device names.

Sounds reasonable to me.  I just wanted longer device names, I didn't want
unlimited ones. :-)

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert <at> fledge.watson.org      Network Associates Laboratories

On Tue, 4 Feb 2003 phk <at> freebsd.org wrote:

> 
> There are some irritating implications of making device names truly
> variable size, and I am not yet comfortable making the semantic
> changes it causes, people calle makedev() and make_dev() from the
> damnest places.
> 
> In fact, I am not even convinced doing the work would have a positive
> payoff in the end compared to sticking with KISS and just taking
> the memory hit for a longer default buffer.
> 
> I decided to increase the limit to 63 characters for now, and revisit
> the issue if this limit ever becomes a problem.  I personally expect
> and hope that any device name approaching than 63 characters would
> hit against other (esthetical) boundaries first.
> 
> We currently allocate 50 dev_t's at compile time (to be able to
> make it until malloc(9) works) and the rest with malloc(9).  The
> current size of a dev_t is 140 bytes + space for the name, so in
> theory we can allow for 116 bytes long names at a net cost of only
> 50 times the increase since malloc(9) already allocates us 256 bytes
> buckets, so the net cost of this change was 2400 bytes.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane