Re: [Mesa-dev] issue about context reference

2020-10-03 Thread Zhu Yijun 
Now I am using staging/20.1, I will use mesa/master to reproduce it.

Marek Olšák  于2020年10月1日周四 上午2:57写道：

>
> Hi,
>
> Does the issue happen with mesa/master?
>
> Marek
>
>
> On Mon, Sep 28, 2020 at 3:11 AM Zhu Yijun  wrote:
>>
>> hi all,
>>
>> I use qemu/kvm to boot some android guests with virgl and run apks,
>> the host kernel invokes oom after several hours.
>>
>> 1. From /proc/meminfo, I see the 'SUnreclaim' is the largest part.
>>
>> MemTotal: 16553672 kB
>> MemFree: 128688 kB
>> MemAvailable: 34648 kB
>> Slab: 10169908 kB
>> SReclaimable: 64632 kB
>> SUnreclaim: 10105276 kB
>>
>> 2. From slabinfo, 'kmalloc-8192' nearly uses 5G memory which is the
>> largest part of slab.
>>
>> kmalloc-8192 566782 566782 8192 4 8 : tunables 0 0 0 : slabdata 141697 
>> 141697 0
>>
>> 3. Then I append 'slub_debug=U,kmalloc-8192' to host kernel command
>> line to reproduce this issue, find the call number of amdgpu_ctx_free
>> is much less than amdgpu_ctx_alloc after running a few minutes test
>> with only one android guest. It is the reason that 'kmalloc-8192' slab
>> memory increases continuously.
>>
>> #cat /sys/kernel/slab/kmalloc-8192/alloc_calls
>>   2 __vring_new_virtqueue+0x64/0x188 [virtio_ring]
>> age=2779779/2779779/2779779 pid=1069 cpus=19 nodes=0
>>   1 rd_alloc_device+0x34/0x48 [target_core_mod] age=2776755
>> pid=1969 cpus=20 nodes=0
>>   2 mb_cache_create+0x7c/0x128 [mbcache]
>> age=2777018/2777221/2777425 pid=1186-1810 cpus=3,36 nodes=0
>>   2 ext4_fill_super+0x128/0x25b0 [ext4]
>> age=2777019/2777222/2777426 pid=1186-1810 cpus=3,36 nodes=0
>>   2 svc_rqst_alloc+0x3c/0x170 [sunrpc] age=2775427/2775462/2775497
>> pid=2346-2636 cpus=36-37 nodes=0
>>   2 cache_create_net+0x4c/0xc0 [sunrpc]
>> age=2737590/2757403/2777217 pid=1280-4987 cpus=20,44 nodes=0
>>   2 rpc_alloc_iostats+0x2c/0x60 [sunrpc]
>> age=2775494/2775495/2775497 pid=2346 cpus=36 nodes=0
>>1570 amdgpu_ctx_init+0xb4/0x2a0 [amdgpu] age=30110/314435/1914218
>> pid=63167 cpus=1-7,9-10,16-20,23,27,29-35,40-47,52,60,63,95,118,120,122-123
>> nodes=0
>>1570 amdgpu_ctx_ioctl+0x198/0x2f8 [amdgpu] age=30110/314435/1914218
>> pid=63167 cpus=1-7,9-10,16-20,23,27,29-35,40-47,52,60,63,95,118,120,122-123
>> nodes=0
>>   2 gfx_v8_0_init_microcode+0x290/0x740 [amdgpu]
>> age=2776838/2776924/2777011 pid=660 cpus=64 nodes=0
>>   2 construct+0xe0/0x4b8 [amdgpu] age=2776819/2776901/2776983
>> pid=660 cpus=64 nodes=0
>>   2 mod_freesync_create+0x68/0x1d0 [amdgpu]
>> age=2776819/2776901/2776983 pid=660 cpus=64 nodes=0
>>   1 kvm_set_irq_routing+0xa8/0x2c8 [kvm_arm_0] age=1909635
>> pid=63172 cpus=56 nodes=0
>>   1 fat_fill_super+0x5c/0xc20 [fat] age=2777014 pid=1817 cpus=49 nodes=0
>>  11 cgroup1_mount+0x180/0x4e0 age=2779901/2779901/2779911 pid=1
>> cpus=1 nodes=0
>>  12 kvmalloc_node+0x64/0xa8 age=35454/1370665/2776188
>> pid=2176-63167 cpus=2,23,34,42,44 nodes=0
>> 128 zswap_dstmem_prepare+0x48/0x78 age=2780252/2780252/2780252
>> pid=1 cpus=19 nodes=0
>>   1 register_leaf_sysctl_tables+0x9c/0x1d0 age=2786535 pid=0 cpus=0 
>> nodes=0
>>   2 do_register_framebuffer+0x298/0x300
>> age=2779680/2783032/2786385 pid=1-656 cpus=0,5 nodes=0
>>   1 vc_do_resize+0xb4/0x570 age=2786385 pid=1 cpus=5 nodes=0
>>   5 vc_allocate+0x144/0x218 age=2776216/2776219/2776224 pid=2019
>> cpus=40 nodes=0
>>   8 arm_smmu_device_probe+0x2d8/0x640 age=2780865/2780894/2780924
>> pid=1 cpus=0 nodes=0
>>   4 __usb_create_hcd+0x44/0x258 age=2780467/2780534/2780599
>> pid=5-660 cpus=0,64 nodes=0
>>   2 xhci_alloc_virt_device+0x9c/0x308 age=2780463/2780476/2780489
>> pid=5-656 cpus=0 nodes=0
>>   1 hid_add_field+0x120/0x320 age=2780373 pid=1 cpus=19 nodes=0
>>   2 hid_allocate_device+0x2c/0x100 age=2780345/2780362/2780380
>> pid=1 cpus=19 nodes=0
>>   1 ipv4_sysctl_init_net+0x44/0x148 age=2737590 pid=4987 cpus=44 nodes=0
>>   1 ipv4_sysctl_init_net+0xa8/0x148 age=2737590 pid=4987 cpus=44 nodes=0
>>   1 ipv4_sysctl_init_net+0xf8/0x148 age=2780293 pid=1 cpus=19 nodes=0
>>   1 netlink_proto_init+0x60/0x19c age=2786498 pid=1 cpus=0 nodes=0
>>   1 ip_rt_init+0x3c/0x20c age=2786473 pid=1 cpus=3 nodes=0
>>   1 ip_rt_init+0x6c/0x20c age=2786472 pid=1 cpus=3 nodes=0
>>   1 udp_init+0xa0/0x108 age=2786472 pid=1 cpus=4 nodes=0
>>
>> # cat /sys/kernel/slab/kmalloc-8192
>> #cat /sys/kernel/slab/kmalloc-8192/free_calls
>>1473  age=4297679817 pid=0 cpus=0 nodes=0
>>  46 rpc_free+0x5c/0x80 [sunrpc] age=1760585/1918856/1935279
>> pid=33422-68056 cpus=32,34,38,40-42,48,55,57,59,61-63 nodes=0
>>   1 rpc_free_iostats+0x14/0x20 [sunrpc] age=2776482 pid=2346 cpus=36 
>> nodes=0
>> 122 free_user_work+0x30/0x40 [ipmi_msghandler]
>> age=59465/347716/1905020 pid=781-128311 cpus=32-46,50,52,63 nodes=0
>> 740 amdgpu_ctx_fini+0x98/0xc8 [amdgpu] age=32012/286664/1910687
>> pid=63167-63222
>> cpus=1-11,16-24,27,29-35,40,42-45,47,52,60,63,95,118,120,122-123
>> nodes=0
>> 719

Re: [Mesa-dev] Rust drivers in Mesa

2020-10-03 Thread Konstantin Kharlamov 
On Sat, 2020-10-03 at 00:51 +0200, timur.kris...@gmail.com wrote:
> The Rust syntax is slightly annoying. They departed from C/C++ enough
> to make Rust look different, but then they got lazy and for some reason
> they chose to keep the most annoying parts from C/C++ like curly braces
> and semicolons, so even if we switch to Rust we can still enjoy
> debating important topics like where to put curly braces, how many
> spaces or tabs are best, and so on.

Unlike C++ though, Rust have reason for semicolons. In Rust you can write a
subexpression, whose result gets assigned to a variable, and you "return" this
result from the subexpression by omitting semicolon. In C++ you have to use a
lambda for that.

Talking of syntax, it may not be ideal, but since you compare it to C++, Rust
syntax is better. Off the top of my head:

1. No "const" modifiers, everything is immutable by default, which is how modern
   language should look like (because really, most of the things you work with 
in
   a function are either never modified (e.g. some arguments) or only upon
   creation — i.e. basically never too)
2. No braces in if-conditions. So you have one less pair of braces to eyeball
   while reading complex `if ((foo()+x) && (bar()) || buzz())` statements.
3. Lambda syntax is less to write and to read: less brackets/braces.
4. Way better syntax for Algebraic Data Types. E.g. in C++ you might have a
   `std::variant MyADT`, where all thee fields are ultimately
   anonymous, they only have type. In Rust on the other hand you have a `enum
   MyADT {Event1(Foo), Event2(bar), Event3(Buzz)}`, and you know what these 
types
   actually represent.
   
   I recall in modern C++ you can use `union`, but then you have to wrap it with
   something that tracks the field currently set; and I guess that alone shows 
it
   is more to write than in Rust.
   
These are just something I remember offhand, I'm sure there're more examples
regarding syntax.

> My main concern is that memory is just one of many resources that we
> need to use safely, but it's the only one that Rust concerns itself
> with. Memory safety can give you a false sense of security. It's
> possible to write insecure apps that are perfectly memory safe.

Well, this is a correct thought, but I don't see what point are you trying to
make here. I mean, you can write a bad program in any existing language,
sure. Rust gets rid of one possible problem, so… one problem less is good, I
guess?

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

2020-10-03 Thread Konstantin Kharlamov 
On Fri, 2020-10-02 at 08:04 -0700, Dylan Baker wrote:

> And if you're not going to use cargo, is rust really a win?

Sure. When people talk about Rust in context of advantages against other
languages, I don't remember Cargo ever being mentioned. People love it for other
reasons.

> The standard library is rather minimal "because just pull in 1000 crates". The
> distro people can correct me if I'm wrong, but when librsvg went to rust it 
> was
> a nightmare, several distros went a long time without updates because of 
> cargo.

IIRC, the problem wit librsvg was because Clang didn't support some CPU
architectures on which librsvg was used. So people simply could not build it. I
don't remember hearing about any other issues.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Rust drivers in Mesa

2020-10-03 Thread Konstantin Kharlamov 
On Sun, 2020-10-04 at 00:48 +0300, Konstantin Kharlamov wrote: The standard
> > library is rather minimal "because just pull in 1000 crates".  The distro
> > people can correct me if I'm wrong, but when librsvg went to rust it was a
> > nightmare, several distros went a long time without updates because of 
> > cargo.
> 
> IIRC, the problem wit librsvg was because Clang 

Sorry, I mean LLVM of course.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev