add prompt-based classifier and first results with DeepSeek-R1:14b

1 files changed, 25 insertions, 0 deletions

diff --git a/results/classifier/deepseek-1/reasoning/load./1847525 b/results/classifier/deepseek-1/reasoning/load./1847525
new file mode 100644
index 000000000..5cc5519a6
--- /dev/null
+++ b/results/classifier/deepseek-1/reasoning/load./1847525
@@ -0,0 +1,25 @@
+<think>
+Okay, so I need to classify this bug report into one of the given categories. Let me read through the report carefully to understand what's going on.
+
+The user is experiencing high CPU usage by qemu-system-i386 after a few hours when running a VM with SDL and GL enabled. They mentioned that the process starts eating more CPU over time, especially noticeable at lower host CPU frequencies. This leads to the guest OS freezing after a day or so.
+
+Looking at the provided information, the user is using QEMU version 4.1.50 and 4.2.91 on a Slackware system with an AMD FX-4300 processor. They've tried different kernels but haven't seen stable results yet. The high CPU usage seems to be causing instability in the guest.
+
+The possible categories are: mistranslation, assembly lowering, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
+
+The user is using SDL and GL options for display, so graphics-related components might be involved. The high CPU usage could relate to rendering or how the GPU is being utilized by QEMU. Alternatively, it might be a performance issue with the way resources are managed, possibly related to KVM or the hypervisor's handling of VM tasks.
+
+I don't see any mention of networking issues, so socket or network categories seem less likely. Similarly, there's no indication of boot failures or VNC problems. The focus is on graphical rendering and CPU usage over time leading to instability.
+
+The issue might be related to how QEMU handles graphics acceleration or resource management under sustained load. Alternatively, it could be a performance bottleneck in the hypervisor itself when running for extended periods.
+
+Given that the user is experiencing high CPU usage specifically with graphical options enabled, it's more likely tied to the graphic subsystem within QEMU rather than general performance issues. However, if it's a broader resource management problem affecting the hypervisor, then 'hypervisor' could be relevant.
+
+But considering the symptoms point towards graphics and sustained load causing increased CPU, I'm leaning towards 'graphic' as the category.
+</think>
+
+The bug report describes high CPU usage in QEMU when running a VM with graphical options enabled (SDL and GL), leading to guest instability. The issue likely relates to how QEMU handles graphics rendering or resource management under extended use. Therefore, the appropriate classification is:
+
+**Graphic**
+
+This categorization reflects the problem's relation to QEMU's graphical subsystem performance under load.
\ No newline at end of file