search for: obj_size

...ject.size(new("A", stuff=raw(0)))? ? ? # 680 bytes > ? ?object.size(new("A", stuff=runif(1e8)))? # 680 bytes > > Why wouldn't object.size() look at the content of environments? > > > As the author, I'm obviously biased, but I do like lobstr::obj_sizes() > which allows you to see the additional size occupied by one object given > any number of other objects. This is particularly important for > reference classes since individual objects appear quite large: > > A <- setRefClass("A", fields=c(stuff="ANY"))...

...>? ? ? ? ?object.size(new("A", stuff=runif(1e8)))? # 680 bytes > > > >? ? ?Why wouldn't object.size() look at the content of environments? > > > > > > As the author, I'm obviously biased, but I do like > lobstr::obj_sizes() > > which allows you to see the additional size occupied by one > object given > > any number of other objects. This is particularly important for > > reference classes since individual objects appear quite large: > > > > A <- setR...

..., stuff=raw(0))) # 680 bytes > > object.size(new("A", stuff=runif(1e8))) # 680 bytes > > > > Why wouldn't object.size() look at the content of environments? > > > > > > As the author, I'm obviously biased, but I do like lobstr::obj_sizes() > > which allows you to see the additional size occupied by one object given > > any number of other objects. This is particularly important for > > reference classes since individual objects appear quite large: > > > > A <- setRefClass("A", fields=c(st...

Hi Tomas, On 3/27/20 07:01, Tomas Kalibera wrote: > they provide an over-approximation They can also provide an "under-approximation" (to say the least) e.g. on reference objects where the entire substance of the object is ignored which makes object.size() completely meaningless in that case: setRefClass("A", fields=c(stuff="ANY"))

...NY")) > object.size(new("A", stuff=raw(0))) # 680 bytes > object.size(new("A", stuff=runif(1e8))) # 680 bytes > > Why wouldn't object.size() look at the content of environments? > As the author, I'm obviously biased, but I do like lobstr::obj_sizes() which allows you to see the additional size occupied by one object given any number of other objects. This is particularly important for reference classes since individual objects appear quite large: A <- setRefClass("A", fields=c(stuff="ANY")) lobstr::obj_size(new("...

.../pipermail/r-help/2020-February/465700.html My apologies for cross-posting, which I am aware is impolite and I should have posted on R-devel in the first place - but I wasn't sure. Here is my question again: I am currently working through Advanced R by H. Wickham and came across the `lobstr::obj_size` function which appears to calculate the size of an object by taking into account whether the same object has been referenced multiple times, e.g. x <- runif(1e6) y <- list(x, x, x) lobstr::obj_size(y) # 8,000,128 B # versus: object.size(y) # 24000224 bytes Reading through `?object.size` i...

...0.html > > My apologies for cross-posting, which I am aware is impolite and I > should have posted on R-devel in the first place - but I wasn't sure. > > Here is my question again: > > I am currently working through Advanced R by H. Wickham and came > across the `lobstr::obj_size` function which appears to calculate the > size of an object by taking into account whether the same object has > been referenced multiple times, e.g. > > x <- runif(1e6) > y <- list(x, x, x) > lobstr::obj_size(y) > # 8,000,128 B > > # versus: > object.size(y) &g...

On 3/27/20 4:39 PM, Herv? Pag?s wrote: > Hi Tomas, > > On 3/27/20 07:01, Tomas Kalibera wrote: >> they provide an over-approximation > > They can also provide an "under-approximation" (to say the least) e.g. > on reference objects where the entire substance of the object is > ignored which makes object.size() completely meaningless in that case: > > ?

...44cc 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sgdma.c +++ b/drivers/gpu/drm/nouveau/nouveau_sgdma.c @@ -227,7 +227,7 @@ nouveau_sgdma_init(struct drm_device *dev) int i, ret; if (dev_priv->card_type < NV_50) { - aper_size = (64 * 1024 * 1024); + aper_size = (512 * 1024 * 1024); obj_size = (aper_size >> NV_CTXDMA_PAGE_SHIFT) * 4; obj_size += 8; /* ctxdma header */ } else { -- 1.6.6.1.476.g01ddb

...ise this to 1GB, 2GB or 4GB? */ + unsigned limit = 512 * 1024; + + /* use up half ramin for the GART ctxdma object */ + aper_size = dev_priv->ramin_rsvd_vram >> 1; + if(aper_size > limit) + aper_size = limit; + aper_size <<= 10; /* each 4KB page needs a 4 byte entry */ + obj_size = (aper_size >> NV_CTXDMA_PAGE_SHIFT) * 4; obj_size += 8; /* ctxdma header */ } else { - /* 1 entire VM page table */ + /* 1 entire VM page table + * TODO: can we raise this so that it can potentially cover all system memory? + */ aper_size = (512 * 1024 * 1024); obj_size =...

...m_free_object_unlocked(obj); > + if (drm_WARN_ON_ONCE(obj->dev, !obj->funcs || !obj->funcs->free)) > + return; > + > + obj->funcs->free(obj); > } > EXPORT_SYMBOL(drm_gem_object_free); > > @@ -1049,9 +1041,9 @@ EXPORT_SYMBOL(drm_gem_vm_close); > * @obj_size: the object size to be mapped, in bytes > * @vma: VMA for the area to be mapped > * > - * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops > - * provided by the driver. Depending on their requirements, drivers can either > - * provide a fault handler in th...

...ree_object_unlocked) - dev->driver->gem_free_object_unlocked(obj); + if (drm_WARN_ON_ONCE(obj->dev, !obj->funcs || !obj->funcs->free)) + return; + + obj->funcs->free(obj); } EXPORT_SYMBOL(drm_gem_object_free); @@ -1049,9 +1041,9 @@ EXPORT_SYMBOL(drm_gem_vm_close); * @obj_size: the object size to be mapped, in bytes * @vma: VMA for the area to be mapped * - * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops - * provided by the driver. Depending on their requirements, drivers can either - * provide a fault handler in their gem_vm_ops (in which...

...ree_object_unlocked) - dev->driver->gem_free_object_unlocked(obj); + if (drm_WARN_ON_ONCE(obj->dev, !obj->funcs || !obj->funcs->free)) + return; + + obj->funcs->free(obj); } EXPORT_SYMBOL(drm_gem_object_free); @@ -1049,9 +1041,9 @@ EXPORT_SYMBOL(drm_gem_vm_close); * @obj_size: the object size to be mapped, in bytes * @vma: VMA for the area to be mapped * - * Set up the VMA to prepare mapping of the GEM object using the gem_vm_ops - * provided by the driver. Depending on their requirements, drivers can either - * provide a fault handler in their gem_vm_ops (in which...

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #18 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to an instance of

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

This is an attempt to fix the issue that some disks' sysfs attributes are not ready at the time its KOBJ_ADD event is sent. The symptom is during device hotplug, udev may fail to find certain attributes, such as serial or wwn, of the disk. As a result the /dev/disk/by-id entries are not created. The cause is device_add_disk emits the uevent before returning, and the callers have to create

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and updates i.MX's dcss driver. The driver was missing from earlier versions and

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk

The race condition is noticed between disk_add() and disk attributes, on virtio-blk hotplug. Userspace listens to the KOBJ_ADD uevent generated in add_disk(). At that point we haven't created the serial attribute file, therefore depending on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get created. As pointed out by Christoph Hellwig in the specific fix [1], virtio-blk