Como configurar o SGE para dispositivos CUDA?

4

Atualmente estou enfrentando o problema de integrar GPU-Servers em um ambiente SGE existente. Usando o google eu encontrei alguns exemplos de clusters onde isso foi configurado, mas nenhuma informação sobre como isso foi feito.

Existe alguma forma de tutorial ou tutorial sobre isso em algum lugar? Ele não precisa ser muito detalhado, mas deve conter informações suficientes para colocar uma "fila de cuda" em funcionamento ...

Obrigado antecipadamente ...

Editar: para configurar um sensor de carga sobre quantas GPUs em um nó são gratuitas, fiz o seguinte:

  • define o modo de computação das GPUs como exclusivo
  • defina as GPUs como modo persistente
  • adicione o seguinte script à configuração do cluster como sensor de carga (e defina-o por 1 segundo)
#!/bin/sh

hostname='uname -n'

while [ 1 ]; do
  read input
  result=$?
  if [ $result != 0 ]; then
    exit 1
  fi
  if [ "$input" == "quit" ]; then
    exit 0
  fi


  smitool='which nvidia-smi'
  result=$?
  if [ $result != 0 ]; then
    gpusav=0
    gpus=0
  else
    gpustotal='nvidia-smi -L|wc -l'
    gpusused='nvidia-smi |grep "Process name" -A 6|grep -v +-|grep -v \|=|grep -v Usage|grep -v "No running"|wc -l'
    gpusavail='echo $gpustotal-$gpusused|bc'
  fi

  echo begin
  echo "$hostname:gpu:$gpusavail"
  echo end
done

exit 0

Nota: Isso obviamente funciona apenas para GPUs NVIDIA

    
por luxifer 17.10.2011 / 10:24

4 respostas

5

A estratégia é bastante simples.

Usando qconf -mc você pode criar um recurso complexo chamado gpu (ou qualquer nome que você queira nomear). A definição de recurso deve ser algo como:

#name               shortcut   type        relop   requestable consumable default  urgency     
#----------------------------------------------------------------------------------------------
gpu                 gpu        INT         <=      YES         YES        0        0

Em seguida, você deve editar suas definições de host exec com qconf -me para definir o número de GPUs em hosts exec que as possuem:

hostname              node001
load_scaling          NONE
complex_values        gpu=2
user_lists            NONE
xuser_lists           NONE
projects              NONE
xprojects             NONE
usage_scaling         NONE
report_variables      NONE

Agora que você configurou seus hosts exec, é possível solicitar recursos do gpu ao enviar tarefas. Por exemplo: qsub -l gpu=1 e gridengine manterão o controle de quantas GPUs estão disponíveis.

Se você tiver mais de um trabalho em execução por nó que usa uma GPU, poderá colocar suas GPUs no modo exclusivo. Você pode fazer isso com o utilitário nvidia-smi .

    
por 17.10.2011 / 19:02
4

O Open Grid Engine adicionou suporte para o sensor de carga da GPU no lançamento de 2011.11 sem a necessidade de nvidia-smi. A saída do aplicativo nvidia-smi pode (e não) mudar entre as versões do driver, então a outra abordagem não é recomendada.

If you have the GE2011.11 source tree, look for: dist/gpu/gpu_sensor.c

To compile the load sensor (need to have the CUDA toolkit on the system):

% cc gpu_sensor.c -lnvidia-ml

And if you just want to see the status reported by the load sensor interactively, compile with:

-DSTANDALONE

To use the load sensor in a Grid Engine cluster, you will just need to follow the standard load sensor setup procedure:

http://gridscheduler.sourceforge.net/howto/loadsensor.html

Fontes:

  1. link
por 14.02.2012 / 01:21
2

Quando você tem várias GPUs e deseja que suas tarefas solicitem uma GPU, mas o planejador do Grid Engine deve manipular e selecionar as GPUs gratuitas , você pode configurar um complexo RSMAP (mapa de recursos) (em vez de um INT). Isso permite especificar a quantidade e os nomes das GPUs em um host específico na configuração do host. Você também pode configurá-lo como um consumível HOST, de modo que independente dos slots sua solicitação, a quantidade de dispositivos GPU solicitada com -l cuda = 2 é para cada host 2 (mesmo que o trabalho paralelo tenha 8 slots em hosts diferentes ).

qconf -mc
    #name               shortcut   type        relop   requestable consumable default  urgency     
    #----------------------------------------------------------------------------------------------
    gpu                 gpu        RSMAP         <=      YES         HOST        0        0

Na configuração do host de execução, você pode inicializar seus recursos com ids / nomes (aqui simplesmente GPU1 e GPU2).

qconf -me yourhost
hostname              yourhost
load_scaling          NONE
complex_values        gpu=2(GPU1 GPU2)

Então, ao solicitar -l gpu = 1, o agendador do Univa Grid Engine selecionará GPU2 se o GPU1 já estiver sendo usado por um trabalho diferente. Você pode ver a seleção real na saída qstat -j. A tarefa obtém a GPU selecionada lendo a variável de ambiente $ SGE_HGR_gpu, que contém, neste caso, o ID / nome "GPU2" escolhido. Isso pode ser usado para acessar a GPU correta sem ter colisões.

Se você tiver um host com vários soquetes, poderá anexar uma GPU diretamente a alguns núcleos de CPU perto da GPU (perto do barramento PCIe) para acelerar a comunicação entre a GPU e as CPUs. Isso é possível anexando uma máscara de topologia na configuração do host de execução.

qconf -me yourhost
hostname              yourhost
load_scaling          NONE
complex_values        gpu=2(GPU1:SCCCCScccc GPU2:SccccSCCCC)

Agora, quando o agendador UGE seleciona GPU2, ele vincula automaticamente o trabalho a todos os 4 núcleos (C) do segundo soquete (S), de modo que o trabalho não possa ser executado no primeiro soquete. Isso nem requer o parâmetro qsub -binding.

Mais exemplos de configuração você pode encontrar em www.gridengine.eu .

Note que todos esses recursos estão disponíveis apenas no Univa Grid Engine (8.1.0 / 8.1.3 e superior), e não no SGE 6.2u5 e outra versão do Grid Engine (como OGE, Sun of Grid Engine etc.) . Você pode experimentá-lo baixando a versão gratuita limitada de 48 núcleos do univa.com.

    
por 05.02.2013 / 08:10
0

Para o SGE 2011.11 que vem com o ROCKS 6.1, achei que a configuração do consumível complexo era:

    #name               shortcut   type        relop   requestable consumable default  urgency     
    #----------------------------------------------------------------------------------------------
    gpu                 gpu        INT         <=      YES         JOB        0        0

Isso permitiu que eu definisse o número de GPUs por nó e, quando eu submeti um trabalho, o número de GPUs solicitadas não dependia da contagem de SMP / SLOT. Eu posso então usar 8 CPUs e 4 GPUs por trabalho e não causar problemas com outros trabalhos vazando. Eu ainda tinha que definir os consumíveis para os nós como acima.

Esta não é uma solução tão boa quanto algumas das outras, mas descobri que a opção RSMAP não estava disponível no SGE 2011.11. Eu gostaria de eventualmente obter este tipo de configuração, assim como eu poderia definir quais GPUs seriam usados.

Espero que isso ajude alguém a economizar algumas horas de configuração.

    
por 09.05.2013 / 21:00