search for: obj_sizes

...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 <- setRe...

..., 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(stu...

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("A...

I have posted this question on R-help where it was suggested to me that I might get a better response on R-devel. So far I have gotten no response. The post I am talking about is here: https://stat.ethz.ch/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

On 2/19/20 3:55 AM, Stefan Schreiber wrote: > I have posted this question on R-help where it was suggested to me > that I might get a better response on R-devel. So far I have gotten no > response. The post I am talking about is here: > https://stat.ethz.ch/pipermail/r-help/2020-February/465700.html > > My apologies for cross-posting, which I am aware is impolite and I >

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: > > ?

This patch enlarges the PCI GART aperture to 512 MB. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophisticated approach may be preferable. In particular, if RAMIN is less than 1MB, a 512MB aperture won't fit. Signed-off-by: Luca Barbieri <luca at luca-barbieri.com> --- drivers/gpu/drm/nouveau/nouveau_sgdma.c

Changes in v2: - Compute size based on ramin_rsvd_size This patch enlarges the PCI GART aperture to 512 MB, or the space covered by a DMA object filling half RAMIN. The current 64MB aperture is too small and should be enlarged. The optimal amound may be card/system-dependent, so a more sophisticated approach may be preferable. Could anyone with an nv04 test whether this doesn't break there?

Hi Thomas. On Thu, Aug 13, 2020 at 10:36:44AM +0200, Thomas Zimmermann wrote: > Several GEM and PRIME callbacks have been deprecated in favor of > per-instance GEM object functions. Remove the callbacks as they are > now unused. The only exception is .gem_prime_mmap, which is still > in use by several drivers. > > What is also gone is gem_vm_ops in struct drm_driver. All

Several GEM and PRIME callbacks have been deprecated in favor of per-instance GEM object functions. Remove the callbacks as they are now unused. The only exception is .gem_prime_mmap, which is still in use by several drivers. What is also gone is gem_vm_ops in struct drm_driver. All drivers now use struct drm_gem_object_funcs.vm_ops instead. While at it, the patch also improves error handling

Several GEM and PRIME callbacks have been deprecated in favor of per-instance GEM object functions. Remove the callbacks as they are now unused. The only exception is .gem_prime_mmap, which is still in use by several drivers. What is also gone is gem_vm_ops in struct drm_driver. All drivers now use struct drm_gem_object_funcs.vm_ops instead. While at it, the patch also improves error handling

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