* Implemented a more elaborated raw memory allocation backend (MemoryManager).
We allocate 8 MB areas whose pages we allocate and map when needed. An area is
divided into equally-sized chunks which form the basic units of allocation. We
have areas with three possible chunk sizes (small, medium, large), which is
basically what the ObjectCache implementations were using anyway.
* Added "uint32 flags" parameter to several of the slab allocator's object
cache and object depot functions. E.g. object_depot_store() potentially wants
to allocate memory for a magazine. But also in pure freeing functions it
might eventually become useful to have those flags, since they could end up
deleting an area, which might not be allowable in all situations. We should
introduce specific flags to indicate that.
* Reworked the block allocator. Since the MemoryManager allocates block-aligned
areas, maintains a hash table for lookup, and maps chunks to object caches,
we can quickly find out which object cache a to be freed allocation belongs
to and thus don't need the boundary tags anymore.
* Reworked the slab boot strap process. We allocate from the initial area only
when really necessary, i.e. when the object cache for the respective
allocation size has not been created yet. A single page is thus sufficient.
other:
* vm_allocate_early(): Added boolean "blockAlign" parameter. If true, the
semantics is the same as for B_ANY_KERNEL_BLOCK_ADDRESS.
* Use an object cache for page mappings. This significantly reduces the
contention on the heap bin locks.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35232 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Updated TODO, we support creating partitions in empty space now. :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35228 a95241bf-73f2-0310-859d-f6bbb57e9c96
One just has to love the write overlay. That one really saved a lot
of work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35224 a95241bf-73f2-0310-859d-f6bbb57e9c96
Installer or continue booting to the Desktop" alert that pops up on CD boots.
It allows to set the language and keymap as the very first thing before a Haiku
installation. (Aside from replacing the alert.) Everything tested and working,
I just need to test integration in the Bootscript.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35221 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added amd64-* as supported host gcc machine.
* Added work-around for AMD64 FreeBSD 8: It only has a static libsupc++,
which prevents us from building shared libraries, so we use the shared
libstdc++ instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35211 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Some changes in the locale roster to allow instanciating a language
- Locale preflet : use this new API instead of directly calling ICU
Side effect : all languages in Locale window are now displayed in the current locale. It makes more sense as otherwise the list would be unsortable. However it can get annoying if you mistakenly set a strange language as default.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35210 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Some coding style fixes along the way.
* Added German translation.
NOTE: The Installer will have to offer a way to change the current locale! So
any translations which are done at this point will have to receive one more
update after I added this feature.
NOTE2: There is something wrong with generating catalogs and the update-all
jam target. If you don't do a clean build, the build won't run through, but it
is enough to build for example an image and then run update-all on your actual
partition profile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35209 a95241bf-73f2-0310-859d-f6bbb57e9c96
the CACHE_DONT_SLEEP flag to work for real, since otherwise the thread could
block on the mutex held by a thread allocating memory. We use two condition
variables to prevent multiple threads from allocating slabs at the same time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35206 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Changed the semantics of object_cache_reserve_internal(). Now it makes sure
the given number of objects are free. As a side effect this also changes
the semantics of object_cache_reserve() similarly, though I have trouble
seeing the purpose of the function in the first place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35204 a95241bf-73f2-0310-859d-f6bbb57e9c96
one for each per CPU store):
* The depot is now protected by a R/W lock combined with a spinlock. It is
required to either hold read lock + spinlock or just the write lock.
* When accessing the per CPU stores we only need to acquire the read lock
and disable interrupts. When switching magazines with the depot we
additionally get the spinlock.
* When allocating a new magazine we do completely unlock.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35200 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The threads beside the main thread are killed earlier now (in the new
team_shutdown_team()), before removing the team from the team hash and from
its process group. This fixes#5296.
* Use a condition variable instead of a semaphore to wait for the non-main
threads to die. We notify the condition right after a thread has left the
team. The semaphore was released by the undertaker.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35196 a95241bf-73f2-0310-859d-f6bbb57e9c96
function is used only in one place and the missing locking would be harmless
if it weren't for the per translation map physical page mapper. It is used to
map the page table for the lookup. Concurrent access could corrupt its data
structures, or, just as bad, the unlocked Query() could remap the page table
used by a concurrent Map() or Unmap(), which would then manipulate the
wrong page table.
Potentially messing up kernel memory, this bug could obviously cause all
kinds of kernel crashes and weird behavior. E.g. ticket #5138 is a likely
candidate, as are triple faults.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35195 a95241bf-73f2-0310-859d-f6bbb57e9c96
layer(s) and logs a timestamp, the thread id, the super volume or super vnode
and interesting bits about call arguments/results to a file (in /var/log). This
can be used for example to debug filesystems without having to manually add
debug output to all the calls, or to analyze access patterns. To add the logging
layer just mount the layer with whatever actual filesystem you have:
mount -t "bfs:log_overlay" /dev/disk/usb/0/0/0 /mountpoint
This would then create the logfile /var/log/log_overlay_dev_disk_usb_0_0_0.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35194 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When the zip file was really large, it was possible the Height passed to SetZoomLimit exceeded the maximum allowed size. Now, we clip at 32767.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35193 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Now takes the screen size into consideration when enlarging the window (fixing ticket #5280)
* Enables Zooming capabilities
* Remembers the last height of the window so that clicking Show contents on and off just returns it to the previous height.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35188 a95241bf-73f2-0310-859d-f6bbb57e9c96
output size, if not it will not show up in the dynamically generated
translator list. Folow up on ticket #4874.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35186 a95241bf-73f2-0310-859d-f6bbb57e9c96
Ignore "NetFS" OptionalPackage in the installoptionalpackage script. It is a
source code only optional package which needs to be compiled from within the
tree.
Thanks a lot! Fixes#5297.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35184 a95241bf-73f2-0310-859d-f6bbb57e9c96
idea, since that would potentially add the object back to the object store
or lead to infinite recursion. When the object cache is destroyed it most
likely led to infinite loops, because the object would alternately be
removed from and added back to the object store.
* delete_object_cache(): Lock after destroying the object store, so we don't
deadlock.
* Use the object store on SMP machines. It seems to work, though I only
tested with the network stack and that seems to have problems of its own.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35182 a95241bf-73f2-0310-859d-f6bbb57e9c96
